This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] [BZ #18433] Check file access/existence before forking.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, navid Rahimi <rahimi dot nv at gmail dot com>, Phil Blundell <pb at pbcl dot net>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Fri, 18 Sep 2015 10:44:46 -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>
On 09/11/2015 05:08 AM, Szabolcs Nagy wrote:
> On 10/09/15 22:45, navid Rahimi wrote:
>> On Thu, Sep 10, 2015 at 10:56 PM, Phil Blundell <email@example.com> wrote:
>>> On Thu, 2015-09-10 at 19:35 +0430, Navid Rahimi wrote:
>>>> I think our main objection here is to avoid forking when there is no
>>>> file.There is so many other variable for checking if execve is going to
>>>> success or not.
>>> On the other hand, your patch will add an extra system call and
>>> directory lookup to every successful posix_spawn() call, i.e. you are
>>> optimising the failure case at the expense of the successful case. It's
>>> not at all obvious to me that this is a sensible thing to do. Can you
>>> explain your reasoning in a bit more detail?
>> I agree with you completely about overhead and extra syscall , but
>> there is no other option if we want to check fork. About optimizing
> there are other options.
> for example you can correctly check if execve returned
> and report an error then instead of doing approximations
> of the right check.
> you can report the error through a cloexec pipe to the parent.
> note that a correct posix_spawn implementation never uses
> fork for QoI reasons (that's the point of posix_spawn, so
> it works on nommu, large multi-thread applications etc.)
> and vfork has the wrong semantics for c code so there are
> other issues here.
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.