Re: Openat first step passfd api

[Bastien ROUCARIES]

Le mercredi 2 février 2011 19:47:24, Paul Eggert a écrit :
> On 02/02/11 09:48, Bastien ROUCARIES wrote:
> > I use emac, could you give me the style used or indent command line ?
> > Thank you
> 
> Please see the existing Gnulib code for examples of
> the style, for example, lib/openat.c.  It is documented in
> <http://www.gnu.org/prep/standards/html_node/Formatting.html>.
> 
> > No long lived see the test file. For old linux, I will not use this
> > but clone with CLONE_VM,!CLONE_FS,CLONE_FILES,CLONE_SIGHAND so it will
> > be faster than fork and without calling sendfd
> 
> OK, thanks, I think I understand: you want openat to fork a
> child that will do the chdir and the work, send
> the fd back to the parent, and immediately exit.
> Presumably there will also be a way for the child to report errno for
> failed 'open' as well.  This removes my objection about long-lived
> processes.

Exactly child will report errno by using a send to the socket after the exit

> 
> Still, I see a couple of problems that you might want to think
> about.
> 
> Offhand I don't see how to use this approach to
> implement functions like 'renameat', which in some
> cases require two working-directory file descriptors.  Perhaps
> these functions should be modified to use the above approach
> on one of the file descriptors, while using the current approach
> on the other?

No problem, it is even simpler because linkat, renameat does not need to pass 
back the fd. fork
fchir to fd2, getpwd, concat path,fchir to fd1, exec rename, return error code

> Also, what happens if there's a signal in the middle of the
> emulated 'openat'?  Won't this leak file descriptors?  A leak
> like that might be acceptable, but should be documented.

1.fds are not leaked is in transit per kernel rule (exept some bugs in kernel 
see recent lkml, but it is not a concern because we 
send only a few fd).
2. if father die, children will be killed by SIGPIPE (reseted to normal 
behavior) during sendmsg or exit normally (and reaped by 
child reaper).
3. because i will use select before using recvfd, i am able to treat the child 
premature die, and return a meaningfull error 
(likely a faked ENOMEM)
4. signal safety of at function. According to last posix at function are safe 
to be called signal handler. It will be safe to call 
at function because i use fork, waitpid and select, recvfd that are safe in 
signal handler.
5 the major problem is sigcld, and fall in the same familly of problem than 
system:
so we need to block sigcld, or if we do not want to block sigchld do some 
creative work on signal handler due to *. And if we 
block we could have some spurious sigchld (but could be documented at least).

Bastien



*POSIX.1-2001 specifies that if the disposition of SIGCHLD is set to SIG_IGN or 
the SA_NOCLDWAIT flag is set for SIGCHLD (see     
sigaction(2)), then children that terminate do not become zombies and a call to 
wait() or waitpid() 
          will block until all children have terminated, and then fail with 
errno set to ECHILD. (The original POSIX standard left 
the behaviour of setting SIGCHLD to SIG_IGN unspecified.)
        ii/ 




I see three case