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

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

sigqueue_free: fix the race with collect_signal()

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

commit 60187d2708caa870f0825d753df1612ea688eb9e in mainline.

Spotted by taoyue  and Jeremy Katz .

collect_signal:				sigqueue_free:

	list_del_init(&first->list);
						if (!list_empty(&q->list)) {
							// not taken
						}
						q->flags &= ~SIGQUEUE_PREALLOC;

	__sigqueue_free(first);			__sigqueue_free(q);

Now, __sigqueue_free() is called twice on the same "struct sigqueue" with the
obviously bad implications.

In particular, this double free breaks the array_cache->avail logic, so the
same sigqueue could be "allocated" twice, and the bug can manifest itself via
the "impossible" BUG_ON(!SIGQUEUE_PREALLOC) in sigqueue_free/send_sigqueue.

Hopefully this can explain these mysterious bug-reports, see

	http://marc.info/?t=118766926500003
	http://marc.info/?t=118466273000005

Alexey Dobriyan reports this patch makes the difference for the testcase, but
nobody has an access to the application which opened the problems originally.

Also, this patch removes tasklist lock/unlock, ->siglock is enough.

Signed-off-by: Oleg Nesterov 
Cc: taoyue 
Cc: Jeremy Katz 
Cc: Sukadev Bhattiprolu 
Cc: Alexey Dobriyan 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Roland McGrath 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

setpgid(child) fails if the child was forked by sub-thread

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

commit b07e35f94a7b6a059f889b904529ee907dc0634d in mainline tree

Spotted by Marcin Kowalczyk .

sys_setpgid(child) fails if the child was forked by sub-thread.

Fix the "is it our child" check. The previous commit
ee0acf90d320c29916ba8c5c1b2e908d81f5057d was not complete.

(this patch asks for the new same_thread_group() helper, but mainline doesn't
 have it yet).

Signed-off-by: Oleg Nesterov 
Acked-by: Roland McGrath 
Tested-by: "Marcin 'Qrczak' Kowalczyk" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

signalfd: fix interaction with posix-timers

2007-08-31T06:01:01+00:00

dequeue_signal:

	if (__SI_TIMER) {
		spin_unlock(&tsk->sighand->siglock);
		do_schedule_next_timer(info);
		spin_lock(&tsk->sighand->siglock);
	}

Unless tsk == curent, this is absolutely unsafe: nothing prevents tsk from
exiting. If signalfd was passed to another process, do_schedule_next_timer()
is just wrong.

Add yet another "tsk == current" check into dequeue_signal().

This patch fixes an oopsable bug, but breaks the scheduling of posix timers
if the shared __SI_TIMER signal was fetched via signalfd attached to another
sub-thread. Mostly fixed by the next patch.

Signed-off-by: Oleg Nesterov 
Cc: Benjamin Herrenschmidt 
Cc: Davide Libenzi 
Cc: Ingo Molnar 
Cc: Michael Kerrisk 
Cc: Roland McGrath 
Cc: Thomas Gleixner 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

Hibernation: do not try to mark invalid PFNs as nosave

2007-08-22T23:23:26+00:00

On some systems some PFNs reported by the early initialization code as 'nosave'
may be invalid. =A0If we try to set the corresponding bits in the hibernation
bitmap, BUG_ON() in memory_bm_find_bit() will be triggered and the system
won't be able to boot (cf. https://bugzilla.novell.com/show_bug.cgi?id=296242).

Prevent this from happening by verifying if the 'nosave' PFNs are valid in
mark_nosave_pages().

Signed-off-by: Rafael J. Wysocki 
Acked-by: Pavel Machek 
Signed-off-by: Greg Kroah-Hartman

fix oops in __audit_signal_info()

2007-08-15T16:25:08+00:00

	Check for audit_signals is misplaced and check for
audit_dummy_context() is missing; as the result, if we send
signal to auditd from task with NULL ->audit_context while
we have audit_signals != 0 we end up with an oops.

Signed-off-by: Al Viro 
Acked-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

destroy_workqueue() can livelock

2007-08-09T21:27:41+00:00

Pointed out by Michal Schmidt .

The bug was introduced in 2.6.22 by me.

cleanup_workqueue_thread() does flush_cpu_workqueue(cwq) in a loop until
->worklist becomes empty.  This is live-lockable, a re-niced caller can get
CPU after wake_up() and insert a new barrier before the lower-priority
cwq->thread has a chance to clear ->current_work.

Change cleanup_workqueue_thread() to do flush_cpu_workqueue(cwq) only once.
 We can rely on the fact that run_workqueue() won't return until it flushes
all works.  So it is safe to call kthread_stop() after that, the "should
stop" request won't be noticed until run_workqueue() returns.

Signed-off-by: Oleg Nesterov 
Cc: Michal Schmidt 
Cc: Srivatsa Vaddagiri 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman