lwn.git/kernel, branch v2.6.22.14

fix param_sysfs_builtin name length check

2007-11-21T17:25:53+00:00

patch 22800a2830ec07e7cc5c837999890ac47cc7f5de in mainline. Commit faf8c714f4508207a9c81cc94dafc76ed6680b44 caused a regression: parameter names longer than MAX_KBUILD_MODNAME will now be rejected, although we just need to keep the module name part that short. This patch restores the old behaviour while still avoiding that memchr is called with its length parameter larger than the total string length. Signed-off-by: Jan Kiszka Cc: Dave Young Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

Fix compat futex hangs.

2007-11-21T17:25:52+00:00

[FUTEX]: Fix address computation in compat code. [ Upstream commit: 3c5fd9c77d609b51c0bab682c9d40cbb496ec6f1 ] compat_exit_robust_list() computes a pointer to the futex entry in userspace as follows: (void __user *)entry + futex_offset 'entry' is a 'struct robust_list __user *', and 'futex_offset' is a 'compat_long_t' (typically a 's32'). Things explode if the 32-bit sign bit is set in futex_offset. Type promotion sign extends futex_offset to a 64-bit value before adding it to 'entry'. This triggered a problem on sparc64 running 32-bit applications which would lock up a cpu looping forever in the fault handling for the userspace load in handle_futex_death(). Compat userspace runs with address masking (wherein the cpu zeros out the top 32-bits of every effective address given to a memory operation instruction) so the sparc64 fault handler accounts for this by zero'ing out the top 32-bits of the fault address too. Since the kernel properly uses the compat_uptr interfaces, kernel side accesses to compat userspace work too since they will only use addresses with the top 32-bit clear. Because of this compat futex layer bug we get into the following loop when executing the get_user() load near the top of handle_futex_death(): 1) load from address '0xfffffffff7f16bd8', FAULT 2) fault handler clears upper 32-bits, processes fault for address '0xf7f16bd8' which succeeds 3) goto #1 I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto for their tireless efforts helping me track down this bug. Signed-off-by: David S. Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

wait_task_stopped: Check p->exit_state instead of TASK_TRACED (CVE-2007-5500)

2007-11-16T18:26:41+00:00

patch a3474224e6a01924be40a8255636ea5522c1023a in mainline The original meaning of the old test (p->state > TASK_STOPPED) was "not dead", since it was before TASK_TRACED existed and before the state/exit_state split. It was a wrong correction in commit 14bf01bb0599c89fc7f426d20353b76e12555308 to make this test for TASK_TRACED instead. It should have been changed when TASK_TRACED was introducted and again when exit_state was introduced. Signed-off-by: Roland McGrath Cc: Oleg Nesterov Cc: Alexey Dobriyan Cc: Kees Cook Acked-by: Scott James Remnant Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

param_sysfs_builtin memchr argument fix

2007-11-05T17:56:07+00:00

patch faf8c714f4508207a9c81cc94dafc76ed6680b44 in mainline. If memchr argument is longer than strlen(kp->name), there will be some weird result. It will casuse duplicate filenames in sysfs for the "nousb". kernel warning messages are as bellow: sysfs: duplicate filename 'usbcore' can not be created WARNING: at fs/sysfs/dir.c:416 sysfs_add_one() [] sysfs_add_one+0xa0/0xe0 [] create_dir+0x48/0xb0 [] sysfs_create_dir+0x29/0x50 [] create_dir+0x1b/0x50 [] kobject_add+0x46/0x150 [] kobject_init+0x3a/0x80 [] kernel_param_sysfs_setup+0x50/0xb0 [] param_sysfs_builtin+0xee/0x130 [] param_sysfs_init+0x23/0x60 [] __next_cpu+0x12/0x20 [] kernel_init+0x0/0xb0 [] kernel_init+0x0/0xb0 [] do_initcalls+0x46/0x1e0 [] create_proc_entry+0x52/0x90 [] register_irq_proc+0x9c/0xc0 [] proc_mkdir_mode+0x34/0x50 [] kernel_init+0x0/0xb0 [] kernel_init+0x62/0xb0 [] kernel_thread_helper+0x7/0x14 ======================= kobject_add failed for usbcore with -EEXIST, don't try to register things with the same name in the same directory. [] kobject_add+0xf6/0x150 [] kernel_param_sysfs_setup+0x50/0xb0 [] param_sysfs_builtin+0xee/0x130 [] param_sysfs_init+0x23/0x60 [] __next_cpu+0x12/0x20 [] kernel_init+0x0/0xb0 [] kernel_init+0x0/0xb0 [] do_initcalls+0x46/0x1e0 [] create_proc_entry+0x52/0x90 [] register_irq_proc+0x9c/0xc0 [] proc_mkdir_mode+0x34/0x50 [] kernel_init+0x0/0xb0 [] kernel_init+0x62/0xb0 [] kernel_thread_helper+0x7/0x14 ======================= Module 'usbcore' failed to be added to sysfs, error number -17 The system will be unstable now. Signed-off-by: Dave Young Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

genirq: suppress resend of level interrupts

2007-11-05T17:56:06+00:00

patch 2464286ace55b3abddfb9cc30ab95e2dac1de9a6 in mainline. Level type interrupts are resent by the interrupt hardware when they are still active at irq_enable(). Suppress the resend mechanism for interrupts marked as level. Signed-off-by: Thomas Gleixner Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

genirq: cleanup mismerge artifact

2007-11-05T17:56:06+00:00

patch 496634217e5671ed876a0348e9f5b7165e830b20 in mainline. Commit 5a43a066b11ac2fe84cf67307f20b83bea390f83: "genirq: Allow fasteoi handler to retrigger disabled interrupts" was erroneously applied to handle_level_irq(). This added the irq retrigger / resend functionality to the level irq handler. Revert the offending bits. Signed-off-by: Thomas Gleixner Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

lockdep: fix mismatched lockdep_depth/curr_chain_hash

2007-11-02T15:44:16+00:00

patch 3aa416b07f0adf01c090baab26fb70c35ec17623 in mainline. lockdep: fix mismatched lockdep_depth/curr_chain_hash It is possible for the current->curr_chain_key to become inconsistent with the current index if the chain fails to validate. The end result is that future lock_acquire() operations may inadvertently fail to find a hit in the cache resulting in a new node being added to the graph for every acquire. [ peterz: this might explain some of the lockdep is so _slow_ complaints. ] [ mingo: this does not impact the correctness of validation, but may slow down future operations significantly, if the chain gets very long. ] Signed-off-by: Gregory Haskins Signed-off-by: Peter Zijlstra Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

Fix timer_stats printout of events/sec

2007-10-10T17:50:16+00:00

commit 74922be1485818ed368c4cf4f0b100f70bf01e08 upstream. When using /proc/timer_stats on ppc64 I noticed the events/sec field wasnt accurate. Sometimes the integer part was incorrect due to rounding (we werent taking the fractional seconds into consideration). The fraction part is also wrong, we need to pad the printf statement and take the bottom three digits of 1000 times the value. Signed-off-by: Anton Blanchard Acked-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Fix SMP poweroff hangs

2007-10-10T17:50:16+00:00

commit 4047727e5ae33f9b8d2b7766d1994ea6e5ec2991 from upstream We need to disable all CPUs other than the boot CPU (usually 0) before attempting to power-off modern SMP machines. This fixes the hang-on-poweroff issue on my MythTV SMP box, and also on Thomas Gleixner's new toybox. Signed-off-by: Mark Lord Acked-by: Thomas Gleixner Cc: "Rafael J. Wysocki" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

futex_compat: fix list traversal bugs

2007-09-26T17:54:40+00:00

commit 179c85ea53bef807621f335767e41e23f86f01df in mainline. The futex list traversal on the compat side appears to have a bug. It's loop termination condition compares: while (compat_ptr(uentry) != &head->list) But that can't be right because "uentry" has the special "pi" indicator bit still potentially set at bit 0. This is cleared by fetch_robust_entry() into the "entry" return value. What this seems to mean is that the list won't terminate when list iteration gets back to the the head. And we'll also process the list head like a normal entry, which could cause all kinds of problems. So we should check for equality with "entry". That pointer is of the non-compat type so we have to do a little casting to keep the compiler and sparse happy. The same problem can in theory occur with the 'pending' variable, although that has not been reported from users so far. Based on the original patch from David Miller. Acked-by: Ingo Molnar Cc: Thomas Gleixner Cc: David Miller Signed-off-by: Arnd Bergmann Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman