linux/kernel, branch v2.6.21.6

[PATCH] timer stats: speedups

2007-06-11T18:36:48Z

Make timer-stats have almost zero overhead when enabled in the config but not used. (this way distros can enable it more easily) Also update the documentation about overhead of timer_stats - it was written for the first version which had a global lock and a linear list walk based lookup ;-) Andrew says: And this. Not a bugfix, but trivial and obvious and apparently some distros don't want to enable timer_stats because of the performance issue, but powertop uses timer_stats. Ingo replies: seconded. I have tested this with and without CONFIG_TIMER_STATS, with and without timer_stats collection activated. Signed-off-by: Ingo Molnar Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] timer statistics: fix race

2007-06-11T18:36:48Z

Fix two races in the timer stats lookup code. One by ensuring that the initialization of a new entry is finished upon insertion of that entry. The other by cleaning up the hash table when the entries array is cleared, so that we don't have any "pre-inserted" entries. Thanks to Eric Dumazet for reminding me of the memory barriers. Signed-off-by: Bjorn Steinbrink Signed-off-by: Ian Kumlien Acked-by: Ingo Molnar Cc: Eric Dumazet Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] Prevent going idle with softirq pending

2007-06-11T18:36:45Z

The NOHZ patch contains a check for softirqs pending when a CPU goes idle. The BUG is unrelated to NOHZ, it just was made visible by the NOHZ patch. The BUG showed up mainly on P4 / hyperthreading enabled machines which lead the investigations into the wrong direction in the first place. The real cause is in cond_resched_softirq(): cond_resched_softirq() is enabling softirqs without invoking the softirq daemon when softirqs are pending. This leads to the warning message in the NOHZ idle code: t1 runs softirq disabled code on CPU#0 interrupt happens, softirq is raised, but deferred (softirqs disabled) t1 calls cond_resched_softirq() enables softirqs via _local_bh_enable() calls schedule() t2 runs t1 is migrated to CPU#1 t2 is done and invokes idle() NOHZ detects the pending softirq Fix: change _local_bh_enable() to local_bh_enable() so the softirq daemon is invoked. Thanks to Anant Nitya for debugging this with great patience ! Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Andrew Morton Cc: Anant Nitya Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] NOHZ: Rate limit the local softirq pending warning output

2007-06-11T18:36:44Z

The warning in the NOHZ code, which triggers when a CPU goes idle with softirqs pending can fill up the logs quite quickly. Rate limit the output until we found the root cause of that problem. Signed-off-by: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] Ignore bogus ACPI info for offline CPUs

2007-06-11T18:36:43Z

Booting a SMP kernel with maxcpus=1 on a SMP system leads to a hard hang, because ACPI ignores the maxcpus setting and sends timer broadcast info for the offline CPUs. This results in a stuck for ever call to smp_call_function_single() on an offline CPU. Ignore the bogus information and print a kernel error to remind ACPI folks to fix it. Affects 2.6.21 / 2.6.22-rc Signed-off-by: Thomas Gleixner Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] cpuset: prevent information leak in cpuset_tasks_read (CVE-2007-2875)

2007-06-07T21:25:31Z

Use simple_read_from_buffer to avoid possible underflow in cpuset_tasks_read which could allow user to read kernel memory. Note: This is fixed upstream in 85badbdf5120d246ce2bb3f1a7689a805f9c9006 Signed-off-by: Chris Wright

[PATCH] clocksource: fix resume logic

2007-05-23T21:32:48Z

We need to make sure that the clocksources are resumed, when timekeeping is resumed. The current resume logic does not guarantee this. Add a resume function pointer to the clocksource struct, so clocksource drivers which need to reinitialize the clocksource can provide a resume function. Add a resume function, which calls the maybe available clocksource resume functions and resets the watchdog function, so a stable TSC can be used accross suspend/resume. Signed-off-by: Thomas Gleixner Cc: john stultz Cc: Andi Kleen Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] highres/dyntick: prevent xtime lock contention

2007-05-23T21:32:46Z

While the !highres/!dyntick code assigns the duty of the do_timer() call to one specific CPU, this was dropped in the highres/dyntick part during development. Steven Rostedt discovered the xtime lock contention on highres/dyntick due to several CPUs trying to update jiffies. Add the single CPU assignement back. In the dyntick case this needs to be handled carefully, as the CPU which has the do_timer() duty must drop the assignement and let it be grabbed by another CPU, which is active. Otherwise the do_timer() calls would not happen during the long sleep. Signed-off-by: Thomas Gleixner Acked-by: Ingo Molnar Cc: Steven Rostedt Acked-by: Mark Lord Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

Allow reading tainted flag as user

2007-04-24T15:23:08Z

The commit 34f5a39899f3f3e815da64f48ddb72942d86c366 restricted reading of the tainted value. The attached patch changes this back to a write-only check and restores the read behaviour of older versions. Signed-off-by: Bastian Blank Cc: Theodore Ts'o Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] fix kernel oops with badly formatted module option

2007-04-12T22:31:41Z

Catch malformed kernel parameter usage of "param = value". Spaces are not supported, but don't cause a kernel fault on such usage, just report an error. Signed-off-by: Randy Dunlap Acked-by: Larry Finger Acked-by: Rusty Russell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds