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

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

futex: pass nr_wake2 to futex_wake_op

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

The fourth argument of sys_futex is ignored when op == FUTEX_WAKE_OP,
but futex_wake_op expects it as its nr_wake2 parameter.

The only user of this operation in glibc is always passing 1, so this
bug had no consequences so far.

Signed-off-by: Andreas Schwab 
Cc: Ingo Molnar 
Signed-off-by: Ulrich Drepper 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

Fix leaks on /proc/{*/sched, sched_debug, timer_list, timer_stats}

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

On every open/close one struct seq_operations leaks.
Kudos to /proc/slab_allocators.

Signed-off-by: Alexey Dobriyan 
Acked-by: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

Fix leak on /proc/lockdep_stats

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

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman