Design change for oplock/open code?

[Jeremy Allison]

On Thu, May 16, 2013 at 04:17:49PM +0200, Volker Lendecke wrote:
> On Thu, May 16, 2013 at 06:44:24AM -0700, Jeremy Allison wrote:
> > 
> > This doesn't look safe. You're leaving us as root
> > across an async call.
> > 
> > Won't connecting to a UNIX domain socket be sync ?
> > Or at least doesn't only the the initial connect()
> > call need to be done as root ?
> > 
> > I'd be much happier with:
> > 
> > +	/* need to be root to connect to CTDB socket */
> > +	become_root();
> > +
> >  	subreq = async_connect_send(state, ev, state->conn->fd,
> >  				    (struct sockaddr *)&state->addr,
> >  				    sizeof(state->addr));
> > 
> > +	unbecome_root();
> > +
> > 
> > Would that work just as well ?
> 
> This is async, right? The real connect(2) in theory might
> happen a lot later.

Doesn't it depend on when the path resolution takes place
within the kernel ? I'm just trying to imaging a scenario
where the connect can block when it's using a UNIX domain
socket pathname, and have to re-resolve the pathname..

But you are completely right, this is tricky and non-specified
and your suggested patch is certainly going to work.

> What about the following patch with the obvoius follow-up?

+1 Reviewed from me.

Whilst researching this issue I did come across various
reports on the web saying a second connect() when the
non-blocking socket reports ready was non-portable.

According to the man page (and the Stevens book) the most
portable way to detect completion is:

       EINPROGRESS
              The socket is nonblocking and the connection cannot be completed immediately.  It is pos‐
              sible  to select(2) or poll(2) for completion by selecting the socket for writing.  After
              select(2) indicates writability, use getsockopt(2) to read the SO_ERROR option  at  level
              SOL_SOCKET  to  determine  whether connect() completed successfully (SO_ERROR is zero) or
              unsuccessfully (SO_ERROR is one of the usual error codes listed here, explaining the rea‐
              son for the failure).

See this page from "Unix Network Programming":

http://books.google.de/books?id=ptSC4LpwGA0C&pg=PA448&lpg=PA448&dq=nonblocking+connect+%22Unix+network+programming%22&source=bl&ots=Kr6FSojqLm&sig=RWA2D1qct01t7FbCHWSli626Ccg&hl=de&sa=X&ei=JxOWUb3tLc_Eswb4g4HYDA&ved=0CDcQ6AEwAA#v=onepage&q=nonblocking%20connect%20%22Unix%20network%20programming%22&f=false

Jeremy.