linux-toradex.git/kernel, branch v2.6.23.9

softlockup: use cpu_clock() instead of sched_clock()

2007-11-26T17:42:32+00:00

patch a3b13c23f186ecb57204580cc1f2dbe9c284953a in mainline.

sched_clock() is not a reliable time-source, use cpu_clock() instead.

Signed-off-by: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

softlockup watchdog fixes and cleanups

2007-11-26T17:42:32+00:00

This is a merge of commits a5f2ce3c6024a5bb895647b6bd88ecae5001020a and
43581a10075492445f65234384210492ff333eba in mainline to fix a warning in
the 2.6.23.3 kernel release.

softlockup watchdog: style cleanups

kernel/softirq.c grew a few style uncleanlinesses in the past few
months, clean that up. No functional changes:

text    data     bss     dec     hex filename
1126      76       4    1206     4b6 softlockup.o.before
1129      76       4    1209     4b9 softlockup.o.after

( the 3 bytes .text increase is due to the "<1>" appended to one of
the printk messages. )

Signed-off-by: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 


softlockup: improve debug output

Improve the debuggability of kernel lockups by enhancing the debug
output of the softlockup detector: print the task that causes the lockup
and try to print a more intelligent backtrace.

The old format was:

BUG: soft lockup detected on CPU#1!
[] show_trace_log_lvl+0x19/0x2e
[] show_trace+0x12/0x14
[] dump_stack+0x14/0x16
[] softlockup_tick+0xbe/0xd0
[] run_local_timers+0x12/0x14
[] update_process_times+0x3e/0x63
[] tick_sched_timer+0x7c/0xc0
[] hrtimer_interrupt+0x135/0x1ba
[] smp_apic_timer_interrupt+0x6e/0x80
[] apic_timer_interrupt+0x33/0x38
[] syscall_call+0x7/0xb
=======================

The new format is:

BUG: soft lockup detected on CPU#1! [prctl:2363]

Pid: 2363, comm:                prctl
EIP: 0060:[] CPU: 1
EIP is at sys_prctl+0x24/0x18c
EFLAGS: 00000213    Not tainted  (2.6.22-cfs-v20 #26)
EAX: 00000001 EBX: 000003e7 ECX: 00000001 EDX: f6df0000
ESI: 000003e7 EDI: 000003e7 EBP: f6df0fb0 DS: 007b ES: 007b FS: 00d8
CR0: 8005003b CR2: 4d8c3340 CR3: 3731d000 CR4: 000006d0
[] show_trace_log_lvl+0x19/0x2e
[] show_trace+0x12/0x14
[] show_regs+0x1ab/0x1b3
[] softlockup_tick+0xef/0x108
[] run_local_timers+0x12/0x14
[] update_process_times+0x3e/0x63
[] tick_sched_timer+0x7c/0xc0
[] hrtimer_interrupt+0x135/0x1ba
[] smp_apic_timer_interrupt+0x6e/0x80
[] apic_timer_interrupt+0x33/0x38
[] syscall_call+0x7/0xb
=======================

Note that in the old format we only knew that some system call locked
up, we didnt know _which_. With the new format we know that it's at a
specific place in sys_prctl(). [which was where i created an artificial
kernel lockup to test the new format.]

This is also useful if the lockup happens in user-space - the user-space
EIP (and other registers) will be printed too. (such a lockup would
either suggest that the task was running at SCHED_FIFO:99 and looping
for more than 10 seconds, or that the softlockup detector has a
false-positive.)

The task name is printed too first, just in case we dont manage to print
a useful backtrace.

[satyam@infradead.org: fix warning]
Signed-off-by: Ingo Molnar 
Signed-off-by: Satyam Sharma 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ntp: fix typo that makes sync_cmos_clock erratic

2007-11-26T17:42:32+00:00

patch fa6a1a554b50cbb7763f6907e6fef927ead480d9 in mainline.

ntp: fix typo that makes sync_cmos_clock erratic

Fix a typo in ntp.c that has caused updating of the persistent (RTC)
clock when synced to NTP to behave erratically.

When debugging a freeze that arises on my AMD64 machines when I
run the ntpd service, I added a number of printk's to monitor the
sync_cmos_clock procedure.  I discovered that it was not syncing to
cmos RTC every 11 minutes as documented, but instead would keep trying
every second for hours at a time.  The reason turned out to be a typo
in sync_cmos_clock, where it attempts to ensure that
update_persistent_clock is called very close to 500 msec. after a 1
second boundary (required by the PC RTC's spec). That typo referred to
"xtime" in one spot, rather than "now", which is derived from "xtime"
but not equal to it.  This makes the test erratic, creating a
"coin-flip" that decides when update_persistent_clock is called - when
it is called, which is rarely, it may be at any time during the one
second period, rather than close to 500 msec, so the value written is
needlessly incorrect, too.

Signed-off-by: David P. Reed 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

Fix divide-by-zero in the 2.6.23 scheduler code

2007-11-26T17:42:30+00:00

No patch in mainline as this logic has been removed from 2.6.24 so it is
not necessary.


https://bugzilla.redhat.com/show_bug.cgi?id=340161

The problem code has been removed in 2.6.24. The below patch disables
SCHED_FEAT_PRECISE_CPU_LOAD which causes the offending code to be skipped
but does not prevent the user from enabling it.

The divide-by-zero is here in kernel/sched.c:

static void update_cpu_load(struct rq *this_rq)
{
	u64 fair_delta64, exec_delta64, idle_delta64, sample_interval64, tmp64;
	unsigned long total_load = this_rq->ls.load.weight;
	unsigned long this_load =  total_load;
	struct load_stat *ls = &this_rq->ls;
	int i, scale;

	this_rq->nr_load_updates++;
	if (unlikely(!(sysctl_sched_features & SCHED_FEAT_PRECISE_CPU_LOAD)))
		goto do_avg;

	/* Update delta_fair/delta_exec fields first */
	update_curr_load(this_rq);

	fair_delta64 = ls->delta_fair + 1;
	ls->delta_fair = 0;

	exec_delta64 = ls->delta_exec + 1;
	ls->delta_exec = 0;

	sample_interval64 = this_rq->clock - ls->load_update_last;
	ls->load_update_last = this_rq->clock;

	if ((s64)sample_interval64 < (s64)TICK_NSEC)
		sample_interval64 = TICK_NSEC;

	if (exec_delta64 > sample_interval64)
		exec_delta64 = sample_interval64;

	idle_delta64 = sample_interval64 - exec_delta64;

======>	tmp64 = div64_64(SCHED_LOAD_SCALE * exec_delta64, fair_delta64);
	tmp64 = div64_64(tmp64 * exec_delta64, sample_interval64);

	this_load = (unsigned long)tmp64;

do_avg:

	/* Update our load: */
	for (i = 0, scale = 1; i < CPU_LOAD_IDX_MAX; i++, scale += scale) {
		unsigned long old_load, new_load;

		/* scale is effectively 1 << i now, and >> i divides by scale */

		old_load = this_rq->cpu_load[i];
		new_load = this_load;

		this_rq->cpu_load[i] = (old_load*(scale-1) + new_load) >> i;
	}
}

For stable only; the code has been removed in 2.6.24.

Signed-off-by: Chuck Ebbert 
Acked-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

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

2007-11-16T18:10:56+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

Fix compat futex hangs.

2007-11-16T16:12:44+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

sched: keep utime/stime monotonic

2007-11-16T16:12:44+00:00

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:43+00:00

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:43+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

param_sysfs_builtin memchr argument fix

2007-11-16T16:12:42+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