This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


In this case I think implementing with vfork would be more readable
and clearer than this tricky hack with pipes and this unavoidable race
condition in fallback mode is something we can avoid with vfork.

If you guys can give any advise I would be more than happy to hear. I
will sent patch for this bug (vfork version ).


I have hard time understanding this part of __spawni function :

  /* Generate the new process.  */
  if ((flags & POSIX_SPAWN_USEVFORK) != 0
      /* If no major work is done, allow using vfork.  Note that we
might perform the path searching.  But this would be done by
a call to execvp(), too, and such a call must be OK according
to POSIX.  */
      || ((flags & (POSIX_SPAWN_SETSIGMASK | POSIX_SPAWN_SETSIGDEF
   | POSIX_SPAWN_SETSCHEDPARAM | POSIX_SPAWN_SETSCHEDULER
   | POSIX_SPAWN_SETPGROUP | POSIX_SPAWN_RESETIDS)) == 0
 && file_actions == NULL))
    new_pid = __vfork ();
  else
    new_pid = __fork ();

Why it is trying to limit usage of vfork ?

best wishes,
-navid


On Sat, Sep 12, 2015 at 1:31 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> Well, you can use pipes provided you have a fallback from pipe2 to pipe in
> the case where __ASSUME_PIPE2 is not defined and pipe2 fails with ENOSYS
> at runtime.  (There would be a race if another thread forks and execs
> between the calls to pipe and fcntl FD_CLOEXEC, but that's unavoidable in
> the absence of pipe2.)
>
> --
> Joseph S. Myers
> joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]