user/sven/linux.git/kernel, branch v2.6.23.3

Fix compat futex hangs.

2007-11-16T16:12:44Z

[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

sched: keep utime/stime monotonic

2007-11-16T16:12:44Z

sched: keep utime/stime monotonic cpustats use utime/stime as a ratio against sum_exec_runtime, as a consequence it can happen - when the ratio changes faster than time accumulates - that either can be appear to go backwards. Combined backport for 2.6.23 of the following patches from mainline: commit 73a2bcb0edb9ffb0b007b3546b430e2c6e415eee Author: Peter Zijlstra sched: keep utime/stime monotonic commit 9301899be75b464ef097f0b5af7af6d9bd8f68a7 Author: Balbir Singh sched: fix /proc//stat stime/utime monotonicity, part 2 Signed-off-by: Frans Pop CC: Peter Zijlstra CC: Balbir Singh Signed-off-by: Greg Kroah-Hartman

fix the softlockup watchdog to actually work

2007-11-16T16:12:43Z

patch a115d5caca1a2905ba7a32b408a6042b20179aaa in mainline. this Xen related commit: commit 966812dc98e6a7fcdf759cbfa0efab77500a8868 Author: Jeremy Fitzhardinge Date: Tue May 8 00:28:02 2007 -0700 Ignore stolen time in the softlockup watchdog broke the softlockup watchdog to never report any lockups. (!) print_timestamp defaults to 0, this makes the following condition always true: if (print_timestamp < (touch_timestamp + 1) || and we'll in essence never report soft lockups. apparently the functionality of the soft lockup watchdog was never actually tested with that patch applied ... Signed-off-by: Ingo Molnar Cc: Jeremy Fitzhardinge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

fix param_sysfs_builtin name length check

2007-11-16T16:12:43Z

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

param_sysfs_builtin memchr argument fix

2007-11-16T16:12:42Z

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

lockdep: fix mismatched lockdep_depth/curr_chain_hash

2007-11-16T16:12:42Z

patch 3aa416b07f0adf01c090baab26fb70c35ec17623 in mainline. 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. Signed-off-by: Gregory Haskins Signed-off-by: Peter Zijlstra Signed-off-by: Ingo Molnar Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

fix bogus reporting of signals by audit

2007-10-07T23:28:43Z

Async signals should not be reported as sent by current in audit log. As it is, we call audit_signal_info() too early in check_kill_permission(). Note that check_kill_permission() has that test already - it needs to know if it should apply current-based permission checks. So the solution is to move the call of audit_signal_info() between those. Bogosity in question is easily reproduced - add a rule watching for e.g. kill(2) from specific process (so that audit_signal_info() would not short-circuit to nothing), say load_policy, watch the bogus OBJ_PID entry in audit logs claiming that write(2) on selinuxfs file issued by load_policy(8) had somehow managed to send a signal to syslogd... Signed-off-by: Al Viro Acked-by: Steve Grubb Acked-by: Eric Paris Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Fix timer_stats printout of events/sec

2007-10-07T23:28:43Z

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 Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

sched: fix profile=sleep

2007-10-02T12:13:08Z

fix sleep profiling - we lost this chunk in the CFS merge. Found-by: Mel Gorman Signed-off-by: Ingo Molnar

robust futex thread exit race

2007-10-01T14:52:23Z

Calling handle_futex_death in exit_robust_list for the different robust mutexes of a thread basically frees the mutex. Another thread might grab the lock immediately which updates the next pointer of the mutex. fetch_robust_entry over the next pointer might therefore branch into the robust mutex list of a different thread. This can cause two problems: 1) some mutexes held by the dead thread are not getting freed and 2) some mutexs held by a different thread are freed. The next point need to be read before calling handle_futex_death. Signed-off-by: Martin Schwidefsky Acked-by: Ingo Molnar Acked-by: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds