Re: [DOCUMENTATION] Revised Unreliable Kernel Locking Guide

[Rusty Russell]

In message <20031212154401.GA10584@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/