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

[PATCH] sched: fix cond_resched_softirq() offset

2007-02-05T16:31:45+00:00

Remove the __resched_legal() check: it is conceptually broken.  The biggest
problem it had is that it can mask buggy cond_resched() calls.  A
cond_resched() call is only legal if we are not in an atomic context, with
two narrow exceptions:

 - if the system is booting
 - a reacquire_kernel_lock() down() done while PREEMPT_ACTIVE is set

But __resched_legal() hid this and just silently returned whenever
these primitives were called from invalid contexts. (Same goes for
cond_resched_locked() and cond_resched_softirq()).

Furthermore, the __legal_resched(0) call was buggy in that it caused
unnecessarily long softirq latencies via cond_resched_softirq().  (which is
only called from softirq-off sections, hence the code did nothing.)

The fix is to resurrect the efficiency of the might_sleep checks and to
only allow the narrow exceptions.

Signed-off-by: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[chrisw: backport to 2.6.19.2]
Signed-off-by: Chris Wright

[PATCH] move_task_off_dead_cpu() should be called with disabled ints

2007-02-05T16:31:45+00:00

move_task_off_dead_cpu() requires interrupts to be disabled, while
migrate_dead() calls it with enabled interrupts.  Added appropriate
comments to functions and added BUG_ON(!irqs_disabled()) into
double_rq_lock() and double_lock_balance() which are the origin sources of
such bugs.

Signed-off-by: Kirill Korotaev 
Acked-by: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright

[PATCH] sched: tasks cannot run on cpus onlined after boot

2007-02-05T16:31:40+00:00

Commit 5c1e176781f43bc902a51e5832f789756bff911b ("sched: force /sbin/init
off isolated cpus") sets init's cpus_allowed to a subset of cpu_online_map
at boot time, which means that tasks won't be scheduled on cpus that are
added to the system later.

Make init's cpus_allowed a subset of cpu_possible_map instead.  This should
still preserve the behavior that Nick's change intended.

Thanks to Giuliano Pochini for reporting this and testing the fix:

http://ozlabs.org/pipermail/linuxppc-dev/2006-December/029397.html

Signed-off-by: Nathan Lynch 
Acked-by: Ingo Molnar 
Cc: Nick Piggin 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright

[PATCH] Fix reparenting to the same thread group. (take 2)

2007-02-05T16:31:40+00:00

This patch fixes the case when we reparent to a different thread in the
same thread group.  This modifies the code so that we do not send
signals and do not change the signal to send to SIGCHLD unless we have
change the thread group of our parents.  It also suppresses sending
pdeath_sig in this cas as well since the result of geppid doesn't
change.

Thanks to Oleg for spotting my bug of only fixing this for non-ptraced
tasks.

This fixes the issues identified by Albert Cahalan in thread
http://lkml.org/lkml/2006/12/21/22.

Signed-off-by: Eric W. Biederman 
Acked-by: Mike Galbraith 
Cc: Albert Cahalan 
Cc: Andrew Morton 
Cc: Roland McGrath 
Cc: Ingo Molnar 
Cc: Coywolf Qi Hunt 
Acked-by: Oleg Nesterov 
Signed-off-by: Linus Torvalds 
[chrisw: fold in 241ceee0b442, Oleg's fix to restore user visible behaviour]
Signed-off-by: Chris Wright

[PATCH] sched: remove __cpuinitdata anotation to cpu_isolated_map

2007-01-10T19:05:18+00:00

The structure cpu_isolated_map is used not only during initialization.
Multi-core scheduler configuration changes and exclusive cpusets
use this during run time.  During setting of sched_mc_power_savings
 policy, this structure is accessed to update sched_domains.

Signed-off-by: Tim Chen 
Acked-by: Suresh Siddha 
Acked-by: Ingo Molnar 
Signed-off-by: Chris Wright

[PATCH] softirq: remove BUG_ONs which can incorrectly trigger

2006-12-11T19:32:40+00:00

It is possible to have tasklets get scheduled before softirqd has had a chance
to spawn on all CPUs.  This is totally harmless; after success during action
CPU_UP_PREPARE, action CPU_ONLINE will be called, which immediately wakes
softirqd on the appropriate CPU to process the already pending tasklets.  So
there is no danger of having a missed wakeup for any tasklets that were
already pending.

In particular, i386 is affected by this during startup, and is visible when
using a very large initrd; during the time it takes for the initrd to be
decompressed, a timer IRQ can come in and schedule RCU callbacks.  It is also
possible that resending of a hardware IRQ via a softirq triggers the same bug.

Because of different timing conditions, this shows up in all emulators and
virtual machines tested, including Xen, VMware, Virtual PC, and Qemu.  It is
also possible to trigger on native hardware with a large enough initrd,
although I don't have a reliable case demonstrating that.

Signed-off-by: Zachary Amsden 
Cc: 
Cc: Ingo Molnar 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Chris Wright

[PATCH] PM: Fix swsusp debug mode testproc

2006-12-11T19:32:40+00:00

The 'testproc' swsusp debug mode thaws tasks twice in a row, which is _very_
confusing.  Fix that.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Pavel Machek 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Chris Wright

Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6

2006-11-29T01:28:41+00:00

* 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6:
  [PATCH] x86-64: Use stricter in process stack check for unwinder
  [PATCH] i386: Fix compilation with UP genericarch
  [PATCH] x86-64: Fix warning in io_apic.c
  [PATCH] x86-64: work around gcc4 issue with -Os in Dwarf2 stack unwind
  [PATCH] x86_64: Align data segment to PAGE_SIZE boundary

[PATCH] fix create_write_pipe() error check

2006-11-29T01:26:50+00:00

The return value of create_write_pipe()/create_read_pipe() should be
checked by IS_ERR().

Signed-off-by: Akinobu Mita 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] x86-64: work around gcc4 issue with -Os in Dwarf2 stack unwind

2006-11-28T19:12:59+00:00

This fixes a problem with gcc4 mis-compiling the stack unwind code under
-Os, which resulted in 'stuck' messages whenever an assembly routine was
encountered.

(The second hunk is trivial cleanup.)

Signed-off-by: Jan Beulich