Date: Fri, 20 Jun 2014 04:16:21 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: Robert Watson <rwatson@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: capability races (was: Re: Seeing ENOTCAPABLE from write FDs in kqueue?) Message-ID: <20140620021621.GC5830@dft-labs.eu> In-Reply-To: <CAJ-Vmon0WDyuSzd53L7uHNPtcoKTyiKTvAFRVdUq-Z=aBgq%2BWg@mail.gmail.com> References: <CAJ-VmonJaqg=WV0eTxknOQr51E5qdhDU=MdoCywz-hwZ57jj6w@mail.gmail.com> <20140608220000.GA5030@dft-labs.eu> <20140608230059.GB5030@dft-labs.eu> <20140618203314.GB7157@dft-labs.eu> <20140620010424.GA5830@dft-labs.eu> <CAJ-Vmon0WDyuSzd53L7uHNPtcoKTyiKTvAFRVdUq-Z=aBgq%2BWg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140620021621.GC5830>