current fd allocation idiom

[Konstantin Belousov]

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:
> > > 
> > > > 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 at gmail.com> 
> > wrote:
> > > > >
> > > > > > I would expect soabort to result in a timeout/reset as opposed to 
> > regular
> > > > > > connection close.
> > > > > >
> > > > > > Comments around soabort suggest it should not be used as a replacement
> > > > > > for close, but maybe this is largely because of what the other end 
> > will
> > > > > > see. That will need to be investigated.
> > > > > >
> > > > > >
> > > > > I added some text regarding soabort to socket.9 in r266962 -- does 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 easily
> > > > 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. :-)
> > > 
> > > Hmm, I was hoping that jhb would chime in and save me from being on the
> > > hook, but it does look like soabort() would be acceptable in this case.
> > 
> > I think having the EMFILE/ENFILE case use the same exact logic as a listen 
> > queue overflow (i.e. soabort()) is correct.
> > 
> 
> So I was playing with converting stuff and I think I hit the wall with
> procdesc.
> 
> 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. what
> 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.

> 
> That said, like previously proposed plan would be:
> 
> where applicable:
> 1. allocate fp
> 2. do stuff
> 3. install fp under free fd
> 
> in cases like procdesc:
> 1. reserve fd
> 2. allocate fp
> 3. do stuff
> 4. install fp
> 
> 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.
> 
> When it comes to avoiding taking filedesc lock multiple times for
> succeedeing case, we can get away with the following:
> 
> 1. finit(..);
> 2. ensure all writes are completed
> 3. fdp->fd_ofiles[fd].fde_file = fp;
> 
> -- 
> Mateusz Guzik <mjguzik gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140824/26e4c1ca/attachment.sig>