Date: Fri, 18 Jul 2014 21:19:28 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-arch@freebsd.org Subject: Re: current fd allocation idiom Message-ID: <20140718191928.GB7179@dft-labs.eu> In-Reply-To: <20140718155959.GN93733@kib.kiev.ua> References: <20140717235538.GA15714@dft-labs.eu> <20140718130629.GJ93733@kib.kiev.ua> <20140718144012.GA7179@dft-labs.eu> <20140718155959.GN93733@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 18, 2014 at 06:59:59PM +0300, Konstantin Belousov wrote: > On Fri, Jul 18, 2014 at 04:40:12PM +0200, Mateusz Guzik wrote: > > On Fri, Jul 18, 2014 at 04:06:29PM +0300, Konstantin Belousov wrote: > > > On Fri, Jul 18, 2014 at 01:55:38AM +0200, Mateusz Guzik wrote: > > > > ============================ > > > > GENERAL OVERVIEW OF CURRENT STATE: > > > > > > > > What readers need to do: > > > > - rmb() after reading fp_ops > > > > - check fp_ops for badfileops > > > How can readers see badfileops ? > > > > > > > Not sure what you mean. fp is installed with badfileops, anything > > accessing fdtable before finit finishes will see this. > I referenced falloc_noinstall(). > There must be some miscommunication. If finstall is not executed fp with badfileops (like in kern_openat), readers obviously cannot find this fp. However, if fdalloc is executed (falloc_noinstall + fdalloc which installs fp), readers can find such fp. The latter is the common pattern in the kernel. > > > It seems that all what is needed is conversion of places using > > > falloc() to falloc_noinstall()/finstall(). > > > > > > > This postpones fd allocation to after interested function did all work > > it wanted to do, which means we would need reliable ways of reverting > > all the work in case allocation failed. I'm not so confident we can do > > that for all current consumers and both current and my proposed approach > > don't impose such requirement. > Cleanup should be identical to the actions done on close(2). > > > > > Of course postponing fd allocation where possible is definitely worth > > doing. > Yes, and after that the rest of the cases should be evaluated. > But my gut feeling is that everything would be converted. > So let's say you accept() a connection. With current code, if you got to accept the connection you got it. With your proposal you may find that you can't allocate any fd and have to close fp. This will be visible as accept + close by the other end, while the caller never saw the connection. My guess is people would complain once they encounter such issue. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140718191928.GB7179>