linux/lib, branch v2.6.16.41

disable debugging version of write_lock()

2006-11-19T23:11:42Z

We've confirmed that the debug version of write_lock() can get stuck for long enough to cause NMI watchdog timeouts and hence a crash. We don't know why, yet. Disable it for now. Also disable the similar read_lock() code. Just in case. Thanks to Dave Olson for reporting and testing. Signed-off-by: Andrew Morton Signed-off-by: Adrian Bunk

Convert idr's internal locking to _irqsave variant

2006-09-18T17:28:17Z

Currently, the code in lib/idr.c uses a bare spin_lock(&idp->lock) to do internal locking. This is a nasty trap for code that might call idr functions from different contexts; for example, it seems perfectly reasonable to call idr_get_new() from process context and idr_remove() from interrupt context -- but with the current locking this would lead to a potential deadlock. The simplest fix for this is to just convert the idr locking to use spin_lock_irqsave(). In particular, this fixes a very complicated locking issue detected by lockdep, involving the ib_ipoib driver's priv->lock and dev->_xmit_lock, which get involved with the ib_sa module's query_idr.lock. Signed-off-by: Roland Dreier Signed-off-by: Adrian Bunk

[TEXTSEARCH]: Fix Boyer Moore initialization bug

2006-09-18T17:26:29Z

The pattern is set after trying to compute the prefix table, which tries to use it. Initialize it before calling compute_prefix_tbl, make compute_prefix_tbl consistently use only the data from struct ts_bm and remove the now unnecessary arguments. Signed-off-by: Michael Rash Signed-off-by: Patrick McHardy Acked-by: David Miller Signed-off-by: Adrian Bunk

idr: fix race in idr code

2006-09-06T14:23:48Z

I ran into a bug where the kernel died in the idr code: cpu 0x1d: Vector: 300 (Data Access) at [c000000b7096f710] pc: c0000000001f8984: .idr_get_new_above_int+0x140/0x330 lr: c0000000001f89b4: .idr_get_new_above_int+0x170/0x330 sp: c000000b7096f990 msr: 800000000000b032 dar: 0 dsisr: 40010000 current = 0xc000000b70d43830 paca = 0xc000000000556900 pid = 2022, comm = hwup 1d:mon> t [c000000b7096f990] c0000000000d2ad8 .expand_files+0x2e8/0x364 (unreliable) [c000000b7096faa0] c0000000001f8bf8 .idr_get_new_above+0x18/0x68 [c000000b7096fb20] c00000000002a054 .init_new_context+0x5c/0xf0 [c000000b7096fbc0] c000000000049dc8 .copy_process+0x91c/0x1404 [c000000b7096fcd0] c00000000004a988 .do_fork+0xd8/0x224 [c000000b7096fdc0] c00000000000ebdc .sys_clone+0x5c/0x74 [c000000b7096fe30] c000000000008950 .ppc_clone+0x8/0xc -- Exception: c00 (System Call) at 000000000fde887c SP (f8b4e7a0) is in userspace Turned out to be a race-condition and NULL ptr deref, here's my fix: Users of the idr code are supposed to call idr_pre_get without locking, so the idr code must serialize itself with respect to layer allocations. However, it fails to do so in an error path in idr_get_new_above_int(). I added the missing locking to fix this. Signed-off-by: Sonny Rao Signed-off-by: Adrian Bunk

Revert mount/umount uevent removal

2006-02-22T17:39:02Z

This change reverts the 033b96fd30db52a710d97b06f87d16fc59fee0f1 commit from Kay Sievers that removed the mount/umount uevents from the kernel. Some older versions of HAL still depend on these events to detect when a new device has been mounted. These events are not correctly emitted, and are broken by design, and so, should not be relied upon by any future program. Instead, the /proc/mounts file should be polled to properly detect this kind of event. A feature-removal-schedule.txt entry has been added, noting when this interface will be removed from the kernel. Signed-off-by: Greg Kroah-Hartman

[PATCH] iomap_copy fallout (m68k)

2006-02-18T21:30:40Z

added __raw_writel(), sanitized include order in iomap_copy.c Signed-off-by: Al Viro

[PATCH] Fix over-zealous tag clearing in radix_tree_delete

2006-02-16T16:45:50Z

If a tag is set for a node being deleted from a radix_tree, then that tag gets cleared from the parent of the node, even if it is set for some siblings of the node begin deleted. This patch changes the logic to include a test for any_tag_set similar to the logic a little futher down. Care is taken to ensure that 'nr_cleared_tags' remains equals to the number of entries in the 'tags' array which are set to '0' (which means that this tag is not set in the tree below pathp->node, and should be cleared at pathp->node and possibly above. [ Nick says: "Linus FYI, I was able to modify the radix tree test harness to catch the bug and can no longer trigger it after the fix. Resulting code passes all other harness tests as well of course." ] Signed-off-by: Neil Brown Acked-by: Nick Piggin Signed-off-by: Linus Torvalds

Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6

2006-02-08T00:29:55Z

[PATCH] Fix spinlock debugging delays to not time out too early

2006-02-08T00:12:33Z

The spinlock-debug wait-loop was using loops_per_jiffy to detect too long spinlock waits - but on fast CPUs this led to a way too fast timeout and false messages. The fix is to include a __delay(1) call in the loop, to correctly approximate the intended delay timeout of 1 second. The code assumes that every architecture implements __delay(1) to last around 1/(loops_per_jiffy*HZ) seconds. Signed-off-by: Ingo Molnar Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Fix uevent buffer overflow in input layer

2006-02-06T20:17:18Z

The buffer used for kobject uevent is too small for some of the events generated by the input layer. Bump it to 2k. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman