public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Rasmus Villemoes <rv@rasmusvillemoes.dk>, libc-alpha@sourceware.org
Subject: Re: [PATCH v2 3/3] posix: New Linux posix_spawn{p} implementation
Date: Wed, 14 Sep 2016 19:37:00 -0000	[thread overview]
Message-ID: <3ec3af54-b733-a894-cb74-d83a947b20d8@linaro.org> (raw)
In-Reply-To: <87mvjsprqb.fsf@rasmusvillemoes.dk>



On 31/08/2016 18:13, Rasmus Villemoes wrote:
>> +	  switch (action->tag)
>> +	    {
>> +	    case spawn_do_close:
>> +	      if ((ret =
>> +		   close_not_cancel (action->action.close_action.fd)) != 0)
>> +		{
>> +		  if (!have_fdlimit)
>> +		    {
>> +		      __getrlimit64 (RLIMIT_NOFILE, &fdlimit);
>> +		      have_fdlimit = true;
>> +		    }
>> +
>> +		  /* Signal errors only for file descriptors out of range.  */
>> +		  if (action->action.close_action.fd < 0
>> +		      || action->action.close_action.fd >= fdlimit.rlim_cur)
>> +		    goto fail;
>> +		}
> 
> I may have missed it in the original discussion, but what is the
> rationale for this? POSIX says
> 
>   If the file_actions argument is not NULL, and specifies any close,
>   dup2, or open actions to be performed, and if posix_spawn() or
>   posix_spawnp() fails for any of the reasons that would cause close(),
>   dup2(), or open() to fail, an error value shall be returned as
>   described by close(), dup2(), and open(), respectively

I haven't joined the original discussion also (if any) for old implementation
behaviour, but I think this conforms to austin group issue #370 [1] where it
changed:

fails for any of the reasons that would cause close( ), dup2( ), or open( ) to
fail, an error value shall be returned

to:

fails for any of the reasons that would cause close( ), dup2( ), or open( ) to
fail, other than attempting a close( ) on a file descriptor that is in range
but already closed, an error value shall be returned

The documentation at [2] seems to not have this updates issues description.

[1] http://austingroupbugs.net/view.php?id=370
[2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn.html

>   
>> +	      break;
>> +
>> +	    case spawn_do_open:
>> +	      {
>> +		ret = open_not_cancel (action->action.open_action.path,
>> +				       action->action.
>> +				       open_action.oflag | O_LARGEFILE,
>> +				       action->action.open_action.mode);
>> +
>> +		if (ret == -1)
>> +		  goto fail;
>> +
>> +		int new_fd = ret;
>> +
>> +		/* Make sure the desired file descriptor is used.  */
>> +		if (ret != action->action.open_action.fd)
>> +		  {
>> +		    if ((ret = __dup2 (new_fd, action->action.open_action.fd))
>> +			!= action->action.open_action.fd)
>> +		      goto fail;
>> +
>> +		    if ((ret = close_not_cancel (new_fd)) != 0)
>> +		      goto fail;
>> +		  }
>> +	      }
> 
> This is also how I'd have implemented it, but POSIX explicitly says
> 
>   If fildes was already an open file descriptor, it shall be closed
>   before the new file is opened.
> 
> Some, if slightly pathological, examples of how the difference could be
> observed:
> 
> * ENFILE/EMFILE

I think this should be an issue iff the program tries call posix_spawn 
with a total number of file descriptors equal to RLIMIT_NOFILE.

> 
> * Some single-open special device; following POSIX,
>   'action_open("/dev/watchdog", 47); action_open("/dev/watchdog", 47);'
>   should both succeed if the first does, whereas the second will fail
>   with the current code.

Right, this should more problematic to handle.  I think an option is to
add a 'fcntl(fd, F_GETFD) != -1 || errno != EBADF' check before the open
syscall and close the file descriptor in this case.

      parent reply	other threads:[~2016-09-14 19:37 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01 16:21 [PATCH 0/3] posix: Execute file function fixes Adhemerval Zanella
2016-02-01 16:21 ` [PATCH v2 1/3] posix: Remove dynamic memory allocation from execl{e,p} Adhemerval Zanella
2016-02-01 16:52   ` Joseph Myers
2016-02-01 17:18     ` Adhemerval Zanella
2016-02-01 17:54       ` Joseph Myers
2016-02-01 18:09         ` Adhemerval Zanella
2016-02-02 11:24       ` Florian Weimer
2016-02-02 12:46         ` Szabolcs Nagy
2016-02-02 12:47         ` Adhemerval Zanella
2016-02-02 16:33     ` Rich Felker
2016-02-07 21:28       ` Rasmus Villemoes
2016-02-09 11:36         ` Richard Henderson
2016-02-09 13:30           ` Szabolcs Nagy
2016-02-10 16:36             ` Adhemerval Zanella
2016-02-01 16:21 ` [PATCH v4 2/3] posix: execvpe cleanup Adhemerval Zanella
2016-02-01 16:21 ` [PATCH v2 3/3] posix: New Linux posix_spawn{p} implementation Adhemerval Zanella
2016-02-02 13:06   ` Florian Weimer
2016-02-02 13:31     ` Adhemerval Zanella
2016-02-03 11:07       ` Torvald Riegel
2016-02-03 12:05         ` Adhemerval Zanella
2016-02-03 12:06           ` Torvald Riegel
2016-02-03 12:14             ` Adhemerval Zanella
2016-08-31 21:13   ` Rasmus Villemoes
2016-08-31 22:08     ` Joseph Myers
2016-09-01  9:28       ` Rasmus Villemoes
2016-09-14 13:13         ` Adhemerval Zanella
2016-09-14 18:58           ` Rasmus Villemoes
2016-09-14 19:59             ` Adhemerval Zanella
2016-09-20 20:25         ` Florian Weimer
2016-09-20 20:54           ` Rasmus Villemoes
2016-09-20 21:01           ` [PATCH] linux: spawni.c: simplify error reporting to parent Rasmus Villemoes
2016-09-22 20:54             ` Adhemerval Zanella
2016-09-23  5:21             ` Florian Weimer
2016-09-23 19:09               ` Rasmus Villemoes
2016-09-23 19:28                 ` Adhemerval Zanella
2016-09-23 20:37                   ` Florian Weimer
2016-09-27 20:26                     ` Rasmus Villemoes
2016-09-27 21:14                       ` Adhemerval Zanella
2016-09-28 14:14             ` Rich Felker
2016-09-28 15:03               ` Andreas Schwab
2016-09-28 15:22                 ` Rich Felker
2016-09-28 18:13                   ` Adhemerval Zanella
2016-10-06 12:52                     ` Florian Weimer
2016-09-06 20:43     ` [PATCH v2 3/3] posix: New Linux posix_spawn{p} implementation Rasmus Villemoes
2016-09-14 19:37     ` Adhemerval Zanella [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ec3af54-b733-a894-cb74-d83a947b20d8@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    --cc=rv@rasmusvillemoes.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).