Re: [RFC][PATCH 0/5] arch: atomic rework

[Paul E. McKenney]

On Wed, Feb 19, 2014 at 06:55:51PM +0100, Torvald Riegel wrote:
> On Wed, 2014-02-19 at 07:14 -0800, Paul E. McKenney wrote:
> > On Wed, Feb 19, 2014 at 11:59:08AM +0100, Torvald Riegel wrote:

[ . . . ]

> > > On both sides, the compiler will see that mmap() (or similar) is called,
> > > so that means the data escapes to something unknown, which could create
> > > threads and so on.  So first, it can't do whole-program analysis for
> > > this state anymore, and has to assume that other C11 threads are
> > > accessing this memory.  Next, lock-free atomics are specified to be
> > > "address-free", meaning that they must work independent of where in
> > > memory the atomics are mapped (see C++ (e.g., N3690) 29.4p3; that's a
> > > "should" and non-normative, but essential IMO).  Thus, this then boils
> > > down to just a simple case of synchronization.  (Of course, the rest of
> > > the ABI has to match too for the data exchange to work.)
> > 
> > The compiler will see mmap() on the user side, but not on the kernel
> > side.  On the kernel side, something special is required.
> 
> Maybe -- you'll certainly know better :)
> 
> But maybe it's not that hard: For example, if the memory is in current
> code made available to userspace via calling some function with an asm
> implementation that the compiler can't analyze, then this should be
> sufficient.

The kernel code would need to explicitly tell the compiler what portions
of the kernel address space were covered by this.  I would not want the
compiler to have to work it out based on observing interactions with the
page tables.  ;-)

> > Agree that "address-free" would be nice as "shall" rather than "should".
> > 
> > > > I echo Peter's question about how one tags functions like mmap().
> > > > 
> > > > I will also remember this for the next time someone on the committee
> > > > discounts "volatile".  ;-)
> > > > 
> > > > > > 5.	JITed code produced based on BPF: https://lwn.net/Articles/437981/
> > > > > 
> > > > > This might be special, or not, depending on how the JITed code gets
> > > > > access to data.  If this is via fixed addresses (e.g., (void*)0x123),
> > > > > then see above.  If this is through function calls that the compiler
> > > > > can't analyze, then this is like 4.
> > > > 
> > > > It could well be via the kernel reading its own symbol table, sort of
> > > > a poor-person's reflection facility.  I guess that would be for all
> > > > intents and purposes equivalent to your (void*)0x123.
> > > 
> > > If it is replacing code generated by the compiler, then yes.  If the JIT
> > > is just filling in functions that had been undefined yet declared
> > > before, then the compiler will have seen the data escape through the
> > > function interfaces, and should be aware that there is other stuff.
> > 
> > So one other concern would then be things things like ftrace, kprobes,
> > ksplice, and so on.  These rewrite the kernel binary at runtime, though
> > in very limited ways.
> 
> Yes.  Nonetheless, I wouldn't see a problem if they, say, rewrite with
> C11-compatible code (and same ABI) on a function granularity (and when
> the function itself isn't executing concurrently) -- this seems to be
> similar to just having another compiler compile this particular
> function.

Well, they aren't using C11-compatible code yet.  They do patch within
functions.  And in some cases, they make staged sequences of changes to
allow the patching to happen concurrently with other CPUs executing the
code being patched.  Not sure that any of the latter is actually in the
kernel at the moment, but it has at least been prototyped and discussed.

							Thanx, Paul

--
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/