linux-toradex.git/lib, branch tegra-10.7.1

dma-debug: allow DMA_BIDIRECTIONAL mappings to be synced with DMA_FROM_DEVICE and

2010-01-18T18:19:33+00:00

commit 42d53b4ff7d61487d18274ebdf1f70c1aef6f122 upstream.

There is no need to perform full BIDIR sync (copying the buffers in case
of swiotlb and similar schemes) if we know that the owner (CPU or device)
hasn't altered the data.

Addresses the false-positive reported at
http://bugzilla.kernel.org/show_bug.cgi?id=14169

Signed-off-by: Krzysztof Halasa 
Cc: David Miller 
Cc: Joerg Roedel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

lib/rational.c needs module.h

2010-01-18T18:19:33+00:00

commit 7ee3aebe31d2cb22c84e1c8f48182947b13a3607 upstream.

lib/rational.c:62: warning: data definition has no type or storage class
lib/rational.c:62: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
lib/rational.c:62: warning: parameter names (without types) in function declaration

Signed-off-by: Sascha Hauer 
Signed-off-by: Uwe Kleine-König 
Acked-by: WANG Cong 
Cc: Oskar Schirmer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

dma-debug: Fix bug causing build warning

2010-01-06T23:03:52+00:00

commit a8fe9ea200ea21421ea750423d1d4d4f7ce037cf upstream.

Stephen Rothwell reported the following build warning:

 lib/dma-debug.c: In function 'dma_debug_device_change':
 lib/dma-debug.c:680: warning: 'return' with no value, in function returning non-void

Introduced by commit f797d9881b62c2ddb1d2e7bd80d87141949c84aa
("dma-debug: Do not add notifier when dma debugging is disabled").

Return 0 [notify-done] when disabled. (this is standard bus notifier behavior.)

Signed-off-by: Shaun Ruffell 
Signed-off-by: Joerg Roedel 
Cc: Linus Torvalds 
LKML-Reference: <20091231125624.GA14666@liondog.tnic>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

dma-debug: Do not add notifier when dma debugging is disabled.

2010-01-06T23:03:51+00:00

commit f797d9881b62c2ddb1d2e7bd80d87141949c84aa upstream.

If CONFIG_HAVE_DMA_API_DEBUG is defined and "dma_debug=off" is
specified on the kernel command line, when you detach a driver from a
device you can cause the following NULL pointer dereference:

BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] dma_debug_device_change+0x5d/0x117

The problem is that the dma_debug_device_change notifier function is
added to the bus notifier chain even though the dma_entry_hash array
was never initialized.  If dma debugging is disabled, this patch both
prevents dma_debug_device_change notifiers from being added to the
chain, and additionally ensures that the dma_debug_device_change
notifier function is a no-op.

Signed-off-by: Shaun Ruffell 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

FS-Cache: Don't delete pending pages from the page-store tracking tree

2009-11-19T18:11:29+00:00

Don't delete pending pages from the page-store tracking tree, but rather send
them for another write as they've presumably been updated.

Signed-off-by: David Howells

FS-Cache: Use radix tree preload correctly in tracking of pages to be stored

2009-11-19T18:11:14+00:00

__fscache_write_page() attempts to load the radix tree preallocation pool for
the CPU it is on before calling radix_tree_insert(), as the insertion must be
done inside a pair of spinlocks.

Use of the preallocation pool, however, is contingent on the radix tree being
initialised without __GFP_WAIT specified.  __fscache_acquire_cookie() was
passing GFP_NOFS to INIT_RADIX_TREE() - but that includes __GFP_WAIT.

The solution is to AND out __GFP_WAIT.

Additionally, the banner comment to radix_tree_preload() is altered to make
note of this prerequisite.  Possibly there should be a WARN_ON() too.

Without this fix, I have seen the following recursive deadlock caused by
radix_tree_insert() attempting to allocate memory inside the spinlocked
region, which resulted in FS-Cache being called back into to release memory -
which required the spinlock already held.

=============================================
[ INFO: possible recursive locking detected ]
2.6.32-rc6-cachefs #24
---------------------------------------------
nfsiod/7916 is trying to acquire lock:
 (&cookie->lock){+.+.-.}, at: [] __fscache_uncache_page+0xdb/0x160 [fscache]

but task is already holding lock:
 (&cookie->lock){+.+.-.}, at: [] __fscache_write_page+0x15c/0x3f3 [fscache]

other info that might help us debug this:
5 locks held by nfsiod/7916:
 #0:  (nfsiod){+.+.+.}, at: [] worker_thread+0x19a/0x2e2
 #1:  (&task->u.tk_work#2){+.+.+.}, at: [] worker_thread+0x19a/0x2e2
 #2:  (&cookie->lock){+.+.-.}, at: [] __fscache_write_page+0x15c/0x3f3 [fscache]
 #3:  (&object->lock#2){+.+.-.}, at: [] __fscache_write_page+0x197/0x3f3 [fscache]
 #4:  (&cookie->stores_lock){+.+...}, at: [] __fscache_write_page+0x19f/0x3f3 [fscache]

stack backtrace:
Pid: 7916, comm: nfsiod Not tainted 2.6.32-rc6-cachefs #24
Call Trace:
 [] __lock_acquire+0x1649/0x16e3
 [] ? __lock_acquire+0x7b7/0x16e3
 [] ? dump_trace+0x248/0x257
 [] lock_acquire+0x57/0x6d
 [] ? __fscache_uncache_page+0xdb/0x160 [fscache]
 [] _spin_lock+0x2c/0x3b
 [] ? __fscache_uncache_page+0xdb/0x160 [fscache]
 [] __fscache_uncache_page+0xdb/0x160 [fscache]
 [] ? __fscache_check_page_write+0x0/0x71 [fscache]
 [] nfs_fscache_release_page+0x86/0xc4 [nfs]
 [] nfs_release_page+0x3c/0x41 [nfs]
 [] try_to_release_page+0x32/0x3b
 [] shrink_page_list+0x316/0x4ac
 [] ? mark_held_locks+0x52/0x70
 [] ? _spin_unlock_irq+0x2b/0x31
 [] shrink_inactive_list+0x392/0x67c
 [] ? mark_held_locks+0x52/0x70
 [] shrink_list+0x8d/0x8f
 [] shrink_zone+0x278/0x33c
 [] ? ktime_get_ts+0xad/0xba
 [] try_to_free_pages+0x22e/0x392
 [] ? isolate_pages_global+0x0/0x212
 [] __alloc_pages_nodemask+0x3dc/0x5cf
 [] cache_alloc_refill+0x34d/0x6c1
 [] ? radix_tree_node_alloc+0x52/0x5c
 [] kmem_cache_alloc+0xb2/0x118
 [] radix_tree_node_alloc+0x52/0x5c
 [] radix_tree_insert+0x57/0x19c
 [] __fscache_write_page+0x1e3/0x3f3 [fscache]
 [] __nfs_readpage_to_fscache+0x58/0x11e [nfs]
 [] nfs_readpage_release+0x34/0x9b [nfs]
 [] nfs_readpage_release_full+0x32/0x4b [nfs]
 [] rpc_release_calldata+0x12/0x14 [sunrpc]
 [] rpc_free_task+0x59/0x61 [sunrpc]
 [] rpc_async_release+0x10/0x12 [sunrpc]
 [] worker_thread+0x1ef/0x2e2
 [] ? worker_thread+0x19a/0x2e2
 [] ? thread_return+0x3e/0x101
 [] ? rpc_async_release+0x0/0x12 [sunrpc]
 [] ? autoremove_wake_function+0x0/0x34
 [] ? trace_hardirqs_on+0xd/0xf
 [] ? worker_thread+0x0/0x2e2
 [] kthread+0x7a/0x82
 [] child_rip+0xa/0x20
 [] ? restore_args+0x0/0x30
 [] ? add_wait_queue+0x15/0x44
 [] ? kthread+0x0/0x82
 [] ? child_rip+0x0/0x20

Signed-off-by: David Howells

strcmp: fix overflow and possibly signedness error

2009-11-19T01:18:13+00:00

Doing the strcmp return value as

	signed char __res = *cs - *ct;

is wrong for two reasons.  The subtraction can overflow because __res
doesn't use a type big enough.  Moreover the compared bytes should be
interpreted as unsigned char as specified by POSIX.

The same problem is fixed in strncmp.

Signed-off-by: Uwe Kleine-König 
Cc: Michael Buesch 
Cc: Andreas Schwab 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

2009-11-05T18:54:08+00:00

* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  x86, fs: Fix x86 procfs stack information for threads on 64-bit
  x86: Add reboot quirk for 3 series Mac mini
  x86: Fix printk message typo in mtrr cleanup code
  dma-debug: Fix compile warning with PAE enabled
  x86/amd-iommu: Un__init function required on shutdown
  x86/amd-iommu: Workaround for erratum 63

dma-debug: Fix compile warning with PAE enabled

2009-10-29T15:25:50+00:00

When PAE is enabled in the kernel configuration the size of
phys_addr_t differs from the size of a void pointer. The gcc
prints a warning about that in dma-debug code.
This patch fixes the warning by converting the output to
unsigned long long instead of a pointer.

Signed-off-by: Joerg Roedel

powerpc: Minor cleanup to lib/Kconfig.debug

2009-10-27T05:42:42+00:00

We don't need an explicit PPC64 in the DEBUG_PREEMPT dependancies as all
PPC platforms now support TRACE_IRQFLAGS_SUPPORT.

Signed-off-by: Kumar Gala 
Signed-off-by: Benjamin Herrenschmidt