Messages in this thread | ![/](/images/icornerl.gif) | | From | Rusty Russell <> | Subject | Re: [DOCUMENTATION] Revised Unreliable Kernel Locking Guide | Date | Mon, 15 Dec 2003 13:28:39 +1100 |
| |
In message <20031212154401.GA10584@redhat.com> you write: > On Fri, Dec 12, 2003 at 04:24:18PM +1100, Rusty Russell wrote: > > OK, I've put the html version up for your reading pleasure: the diff > > is quite extensive and hard to read. > > > > http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/ > > > > Feedback welcome, > > Hi Rusty, > Might be worth mentioning in the Per-CPU data section that code doing > operations on CPU registers (MSRs and the like) needs to be protected > by an explicit preempt_disable() / preempt_enable() pair if it's doing > operations that it expects to run on a specific CPU. > > For examples, see arch/i386/kernel/msr.c & cpuid.c
I don't think it belongs in per-cpu data, that's a bit disingenous. It's a separate section by itself, I think. But it's also fairly rare.
The smp_call_function() case is more subtle, but in fact, there are only two calls to smp_call_function in non-arch-specific code, and both are wrong:
mm/slab.c: smp_call_function_all_cpus() should just be on_each_cpu.
net/core/flow.c: This should also be on_each_cpu: I actually have a patch for this, too.
The aim of this document is to give the reader an overview core techniques, not describe every possible variant. IMHO a more likely candidate for a section would be atomic_dec_and_lock(), which there is no real concept of an "owner" of an object, but the destroy is implicit (and atomic) by the last user.
Hope that clarifies, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |