linux-toradex.git/lib, branch v2.6.32.15

flex_array: fix the panic when calling flex_array_alloc() without __GFP_ZERO

2010-05-12T21:57:00+00:00

commit e59464c735db19619cde2aa331609adb02005f5b upstream.

memset() is called with the wrong address and the kernel panics.

Signed-off-by: Changli Gao 
Cc: Patrick McHardy 
Acked-by: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

block: Backport of various I/O topology fixes from 2.6.33 and 2.6.34

2010-04-01T22:58:56+00:00

block: Backport of various I/O topology fixes from 2.6.33 and 2.6.34

The stacking code incorrectly scaled up the data offset in some cases
causing misaligned devices to report alignment.  Rewrite the stacking
algorithm to remedy this.  

(Upstream commit 9504e0864b58b4a304820dcf3755f1da80d5e72f)

The top device misalignment flag would not be set if the added bottom
device was already misaligned as opposed to causing a stacking failure.
    
Also massage the reporting so that an error is only returned if adding
the bottom device caused the misalignment.  I.e. don't return an error
if the top is already flagged as misaligned.

(Upstream commit fe0b393f2c0a0d23a9bc9ed7dc51a1ee511098bd)


lcm() was defined to take integer-sized arguments.  The supplied
arguments are multiplied, however, causing us to overflow given
sufficiently large input.  That in turn led to incorrect optimal I/O
size reporting in some cases.  Switch lcm() over to unsigned long
similar to gcd() and move the function from blk-settings.c to lib.

Signed-off-by: Martin K. Petersen 
Reviewed-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

idr: fix a critical misallocation bug, take#2

2010-03-15T15:49:37+00:00

commit d2e7276b6b5e4bc2148891a056d5862c5314342d upstream.

This is retry of reverted 859ddf09743a8cc680af33f7259ccd0fd36bfe9d
("idr: fix a critical misallocation bug") which contained two bugs.

* pa[idp->layers] should be cleared even if it's not used by
  sub_alloc() because it's used by mark idr_mark_full().

* The original condition check also assigned pa[l] to p which the new
  code didn't do thus leaving p pointing at the wrong layer.

Both problems have been fixed and the idr code has received good amount
testing using userland testing setup where simple bitmap allocator is
run parallel to verify the result of idr allocation.

The bug this patch fixes is caused by sub_alloc() optimization path
bypassing out-of-room condition check and restarting allocation loop
with starting value higher than maximum allowed value.  For detailed
description, please read commit message of 859ddf09.

Signed-off-by: Tejun Heo 
Based-on-patch-from: Eric Paris 
Reported-by: Eric Paris 
Tested-by: Stefan Lippers-Hollmann 
Tested-by: Serge Hallyn 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

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