This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [BZ #18433] Check file access/existence before forking.
- From: Rich Felker <dalias at libc dot org>
- To: Alexander Monakov <amonakov at ispras dot ru>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Carlos O'Donell <carlos at redhat dot com>, navid Rahimi <rahimi dot nv at gmail dot com>, Phil Blundell <pb at pbcl dot net>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Fri, 18 Sep 2015 15:53:05 -0400
- Subject: Re: [PATCH] [BZ #18433] Check file access/existence before forking.
- Authentication-results: sourceware.org; auth=none
- References: <55F19819 dot 3010601 at gmail dot com> <55F19B66 dot 9050001 at arm dot com> <55F19C50 dot 3010502 at gmail dot com> <1441909606 dot 2948 dot 25 dot camel at pbcl dot net> <CAOUBrm2Kjbk3q+QJACYG24=p1dz60JXimxYG3oRRz2ehpocwkQ at mail dot gmail dot com> <55F299F4 dot 6030907 at arm dot com> <55FC235E dot 6030608 at redhat dot com> <55FC27CB dot 6070602 at arm dot com> <alpine dot LNX dot 2 dot 20 dot 1509181813120 dot 15988 at monopod dot intra dot ispras dot ru>
On Fri, Sep 18, 2015 at 06:19:33PM +0300, Alexander Monakov wrote:
> On Fri, 18 Sep 2015, Szabolcs Nagy wrote:
>
> > On 18/09/15 15:44, Carlos O'Donell wrote:
> > > Note that it is possible to use vfork in certain conditions,
> > > and we do in glibc. So one should not entirely dismiss vfork,
> > > but that's slightly off topic.
> >
> > are you sure?
> >
> > i think all use of vfork is invalid c: the compiler can
> > spill registers on the stack then in the child clobber
> > them, then after vfork returns in the parent the
> > clobbered registers are restored breaking the expectations
> > of the compiler. (this can break independently of how
> > the c code around vfork looks like).
>
> The same argument applies to setjmp,
Not quite. With setjmp, once there's any return from the function
where setjmp was called (or call to a function that's known neither to
return nor call longjmp or throw an exception), the compiler may
rightfully assume that non-reachable data in the setjmp caller is no
longer live and clobber it.
What makes vfork is special is that the data must be treated as live
even when the caller calls _exit.
> and the solution in GCC is the
> same for both: GCC internally recognizes vfork, setjmp, and a few other
> functions as functions that "return twice".
If gcc treats vfork even more specially than setjmp, or slightly
pessimizes behavior around setjmp to force all data to remain live,
then I think it's safe to use vfork as long as your compiler is gcc.
Whether other compilers that are or might become interesting do the
same, I don't know. It's not an assumption I like.
> (after all, if it was broken like you describe, one would expect to witness
> such breakage in practice, for instance with GNU Make prior to 4.0)
I thought the reason GNU make switches was that they encountered
subtle breakage in practice somewhere... Of course GNU make has to be
compatible with basically _all_ compilers, not just gcc, so that might
be the reason.
Rich