Re: [PATCH] [BZ #18433] Check file access/existence before forking.

["Carlos O'Donell" <carlos at redhat 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 <pb@pbcl.net> 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?
>>>
>>> p.
>>>
>>>
>>
>> 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.

c.