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.
prev 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).