Date: Sun, 24 Aug 2014 22:42:40 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Mateusz Guzik <mjguzik@gmail.com> Cc: Benjamin Kaduk <bjk@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: current fd allocation idiom Message-ID: <20140824194240.GY2737@kib.kiev.ua> In-Reply-To: <20140824095901.GA2045@dft-labs.eu> References: <20140717235538.GA15714@dft-labs.eu> <20140813015627.GC17869@dft-labs.eu> <alpine.GSO.1.10.1408151916150.21571@multics.mit.edu> <201408201110.10431.jhb@freebsd.org> <20140824095901.GA2045@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
--D7UQ7r/72P+7HXeb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 24, 2014 at 11:59:01AM +0200, Mateusz Guzik wrote: > On Wed, Aug 20, 2014 at 11:10:10AM -0400, John Baldwin wrote: > > On Friday, August 15, 2014 7:20:03 pm Benjamin Kaduk wrote: > > > On Tue, 12 Aug 2014, Mateusz Guzik wrote: > > >=20 > > > > On Tue, Aug 12, 2014 at 09:31:15PM -0400, Benjamin Kaduk wrote: > > > > > On Tue, Aug 12, 2014 at 7:36 PM, Mateusz Guzik <mjguzik@gmail.com= >=20 > > wrote: > > > > > > > > > > > I would expect soabort to result in a timeout/reset as opposed = to=20 > > regular > > > > > > connection close. > > > > > > > > > > > > Comments around soabort suggest it should not be used as a repl= acement > > > > > > for close, but maybe this is largely because of what the other = end=20 > > will > > > > > > see. That will need to be investigated. > > > > > > > > > > > > > > > > > I added some text regarding soabort to socket.9 in r266962 -- doe= s that > > > > > help clarify the situation? > > > > > > > > > > > > > Nope. :-) > > > > > > > > It is unclear if the only motivation here is making sure nobody else > > > > sees the socket when given thread calls soabort. This would be easi= ly > > > > guaranteed in here: fd allocation failed, fp with given socket was = never > > > > exposed to anyone. > > > > > > > > So, if you say soabort would work here just fine, I'm happy to use = it > > > > and blame you for problems. :-) > > >=20 > > > Hmm, I was hoping that jhb would chime in and save me from being on t= he > > > hook, but it does look like soabort() would be acceptable in this cas= e. > >=20 > > I think having the EMFILE/ENFILE case use the same exact logic as a lis= ten=20 > > queue overflow (i.e. soabort()) is correct. > >=20 >=20 > So I was playing with converting stuff and I think I hit the wall with > procdesc. >=20 > procdesc is instantianed after fork cannot fail anymore. I'm not so sure > we can finish up procdesc for a process which didn't fork yet, and I > seriously doubt we can just kill the new process to revert stuff (e.g. wh= at > about SIGCHLD or kqueue events which fire). We can create the procdesc-attached process in the stopped state. If fp installation went fine, the process is be released (pdfork(2) does not accept rfork(2) flags, so right now there is no issue of conflicting with RFSTOPPED). If installation failed, we can reparent the child to init, kill and release. The fork trampoline should do the right thing; if not, it could be changed to explicitely check for the termination conditions. >=20 > That said, like previously proposed plan would be: >=20 > where applicable: > 1. allocate fp > 2. do stuff > 3. install fp under free fd >=20 > in cases like procdesc: > 1. reserve fd > 2. allocate fp > 3. do stuff > 4. install fp >=20 > This introduces a special case to dup2 when newfd is reserved. Linux > fails in this case with, so I believe we can get away with it as well. >=20 > When it comes to avoiding taking filedesc lock multiple times for > succeedeing case, we can get away with the following: >=20 > 1. finit(..); > 2. ensure all writes are completed > 3. fdp->fd_ofiles[fd].fde_file =3D fp; >=20 > --=20 > Mateusz Guzik <mjguzik gmail.com> --D7UQ7r/72P+7HXeb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT+kAwAAoJEJDCuSvBvK1BluEP/16iGTotw1cTDHAoCLWBAoqi tX0yQ2KOVTzyVa7ZD4laj/rPyfZQu9KhEuFGjvleGNuxhcHfu/c1LyEGlsNzPZze uxy9Z2gOHCK+WX9sOZlrd34uEcpDPL3Ids3BFZzKzwKKvT0tTNRpCneXB1n7eMmo k73iJjtRDkidAGBjm3DadyVrkQr0u/+8gH45kIqUs/pDwXGOmdbwFPa5LBl0LR4p NVSFQ5PBzuMQadvwBVVhYQaLCYyELZ30XFfmAnNktIWTrCWzDgTLfF1eT4gLoPYQ oI8QTklY8AX48SNXpSDx90hOeh9mtPNJJVPYmZ1u9NJUiQhqZb8qEErDCYP89oZM IE0FuVdsQZ1Sg47MzkR6m9s4KQ4PXh2+ZUDxZnqNv6oGgtYmAhrk3TMUl5Chle0p jrdz3cdgsuRfnDyNFp6a+n9YW+RwVxXKvONREZ059sdGr+I9Z6CJCD3vO8oHEJeX NOnZpPCDdZBt/MKtrr5PcSEODAKsRj0diuD7zQkPdEMmm3EkX80KZkPNb2EGjeJ6 18O8hjfWJIjad0TZERxy+USHlkKVcLydW45MDC2Qa3hSkU1nzYhN5PJRggHDno78 vwb2kC+8eN08N3vVTXElgWHeBcfRU8AOBdx44naAPU0/REa3PVQ+MMfX6eGvjy3b ilP4NcUn3gU4SlQZPvoQ =G7Ir -----END PGP SIGNATURE----- --D7UQ7r/72P+7HXeb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140824194240.GY2737>