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: Richard Henderson <rth at twiddle dot net>
- To: Zack Weinberg <zackw at panix dot com>, Andreas Schwab <schwab at linux-m68k dot org>
- Cc: Rich Felker <dalias at libc dot org>, Alexander Monakov <amonakov at ispras dot ru>, 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: Mon, 21 Sep 2015 10:34:53 -0700
- Subject: Re: [PATCH] [BZ #18433] Check file access/existence before forking.
- Authentication-results: sourceware.org; auth=none
- References: <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> <20150918195305 dot GE17773 at brightrain dot aerifal dot cx> <alpine dot LNX dot 2 dot 20 dot 1509182310390 dot 15988 at monopod dot intra dot ispras dot ru> <20150918232634 dot GG17773 at brightrain dot aerifal dot cx> <87k2rmoqtp dot fsf at igel dot home> <CAKCAbMhUnYtJhNUjiVwgT67VTJqRTEXdiwJtED8Bke545RsPXA at mail dot gmail dot com>
On 09/19/2015 08:04 AM, Zack Weinberg wrote:
> On Sat, Sep 19, 2015 at 2:39 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Rich Felker <dalias@libc.org> writes:
>>
>>> Yes, I suppose that's a good way to model it. But the returns_twice
>>> attribute does not specify under what conditions the function returns
>>> again, so unless gcc has vfork-specific knowledge attached to the
>>> specific name, I suppose it must just assume everything stays live.
Indeed it does assume everything stays live.
>>
>> GCC doesn't treat vfork any different from setjmp, or any other function
>> marked returns_twice, see calls.c:special_function_p.
>
> special_function_p just defines the set of functions assumed to have
> this behavior (setjmp, setjmp_syscall, sigsetjmp, savectx, qsetjmp,
> vfork, and getcontext); to find out what the compiler *does* with that
> knowledge you have to grep for ECF_RETURNS_TWICE.
>
> As best I can tell, the direct effects of a callsite being marked
> ECF_RETURNS_TWICE seem to be that it is not eligible for various
> optimizations (e.g. tail call) and, much more importantly, the
> control-flow graph for the containing function is annotated with an
> "abnormal edge" from *every other callsite which is not known to have
> no side effects* to that callsite.
>
> I'm not sure exactly what "abnormal edge" means to GCC, but I think
> this should be conservatively correct, whether or not such a function
> actually does return twice.
Abnormal edge, i.e. abnormal flow of control, i.e. longjmp or throw-like.
It's a big hammer that kills quite a lot of data flow analysis, but thankfully
returns_twice functions are rare. And in the situations they are used, there
usually isn't much room for improvement anyway, so why complicate the
correctness issue?
r~