user/sven/linux.git/kernel/stop_machine.c, branch v2.6.14.7

[PATCH] smp_processor_id() cleanup

2005-06-22T01:46:13Z

This patch implements a number of smp_processor_id() cleanup ideas that Arjan van de Ven and I came up with. The previous __smp_processor_id/_smp_processor_id/smp_processor_id API spaghetti was hard to follow both on the implementational and on the usage side. Some of the complexity arose from picking wrong names, some of the complexity comes from the fact that not all architectures defined __smp_processor_id. In the new code, there are two externally visible symbols: - smp_processor_id(): debug variant. - raw_smp_processor_id(): nondebug variant. Replaces all existing uses of _smp_processor_id() and __smp_processor_id(). Defined by every SMP architecture in include/asm-*/smp.h. There is one new internal symbol, dependent on DEBUG_PREEMPT: - debug_smp_processor_id(): internal debug variant, mapped to smp_processor_id(). Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new lib/smp_processor_id.c file. All related comments got updated and/or clarified. I have build/boot tested the following 8 .config combinations on x86: {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT} I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT. (Other architectures are untested, but should work just fine.) Signed-off-by: Ingo Molnar Signed-off-by: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] use smp_mb/wmb/rmb where possible

2005-05-01T15:58:47Z

Replace a number of memory barriers with smp_ variants. This means we won't take the unnecessary hit on UP machines. Signed-off-by: Anton Blanchard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Missing set_fs() calls around kernel syscall

2005-03-28T11:58:26Z

Found by sparse... since we are passing kernel param to a syscall handler, we need to do the set_fs() wrappers. Signed-off-by: Randolph Chung Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] remove the BKL by turning it into a semaphore

2005-01-08T05:59:57Z

This is the current remove-BKL patch. I test-booted it on x86 and x64, trying every conceivable combination of SMP, PREEMPT and PREEMPT_BKL. All other architectures should compile as well. (most of the testing was done with the zaphod patch undone but it applies cleanly on vanilla -mm3 as well and should work fine.) this is the debugging-enabled variant of the patch which has two main debugging features: - debug potentially illegal smp_processor_id() use. Has caught a number of real bugs - e.g. look at the printk.c fix in the patch. - make it possible to enable/disable the BKL via a .config. If this goes upstream we dont want this of course, but for now it gives people a chance to find out whether any particular problem was caused by this patch. This patch has one important fix over the previous BKL patch: on PREEMPT kernels if we preempted BKL-using code then the code still auto-dropped the BKL by mistake. This caused a number of breakages for testers, which breakages went away once this bug was fixed. Also the debugging mechanism has been improved alot relative to the previous BKL patch. Would be nice to test-drive this in -mm. There will likely be some more smp_processor_id() false positives but they are 1) harmless 2) easy to fix up. We could as well find more real smp_processor_id() related breakages as well. The most noteworthy fact is that no BKL-using code was found yet that relied on smp_processor_id(), which is promising from a compatibility POV. Signed-off-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Fix occasional stop_machine() lockup with > 2 CPUs

2004-12-01T09:10:19Z

Stephen Rothwell noted a case where one CPU was sitting in userspace, one in stop_machine() waiting for everyone to enter stopmachine(). This can happen if migration occurs at exactly the wrong time with more than 2 CPUS. Say we have 4 CPUS: 1) stop_machine() on CPU 0creates stopmachine() threads for CPUS 1, 2 and 3, and yields waiting for them to migrate to their CPUs and ack. 2) stopmachine(2) gets rebalanced (probably on exec) to CPU 1. 3) stopmachine(2) calls set_cpus_allowed on CPU 1, sleeps awaiting migration thread. 4) stopmachine(1) calls set_cpus_allowed on CPU 0, moves onto CPU1 and starts spinning. Now the migration thread never runs, and we deadlock. The simplest solution is for stopmachine() to yield until they are all in place. Signed-off-by: Rusty Russell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] add stop_machine barriers

2004-04-12T06:19:47Z

From: Andrea Arcangeli We need a barrier before checking for kthread_should_stop in do_stop.

[PATCH] Fix obvious stupid race in do_stop

2004-03-30T02:49:13Z

We don't set the task state to TASK_INTERRUPTIBLE _before_ checking for kthread_should_stop in do_stop.

Make sure to include syscalls.h to get proper prototypes.

2004-03-09T09:03:28Z

Especially with REGPARM these things actually matter.

[PATCH] stop_machine_run: Move Bogolock Code Out of module.c

2004-03-08T09:12:45Z

The "bogolock" code was introduced in module.c, as a way of freezing the machine when we wanted to remove a module. This patch moves it out to stop_machine.c and stop_machine.h. Since the code changes affinity and proirity, it's impolite to hijack the current context, so we use a kthread. This means we have to pass the function rather than implement "stop_machine()" and "restart_machine()".