capability races (was: Re: Seeing ENOTCAPABLE from write FDs in kqueue?)

[Mateusz Guzik]

On Thu, Jun 19, 2014 at 07:05:48PM -0700, Adrian Chadd wrote:
> [snip]
> 
> I'm increasingly wary of hand-rolled memory barrier / atomic using
> constructs like this. It's way, way too easy to shoot a foot off on an
> architecture that you don't have or know.
> 

Sure, hence I'm lookin for someone with strong memory-barrier-fu.

> So, if we're going down this rabbit hole further, I think we should
> first define all the places this stuff gets touched and try to come up
> with some behavioral description that we could try and link to some
> existing (non-patent-encumbered) no-lock based design pattern.
> 
> So in your example, yes the pointer assignment is atomic, but there's
> no current guarantee that anything currently operating on that pointer
> has finished. That's what things like RCU address.
> 

But we don't need that guarantee in here. File tables are freed only on
process exit specifically because we never know if all threads finished
reading. File table pointer is refreshed and fp validated before is
returned to the caller; if validation fails there is relookup.

Having RCU-like solution would allow us to free old tables without the
process exiting of course, but would not affect correctness.

As a side note, we could easily free old tables in singlethreaded
processes. Multithreaded would require actual work to make sure all
threads are stopped.

-- 
Mateusz Guzik <mjguzik gmail.com>