From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
akpm@linux-foundation.org, viro@zeniv.linux.org.uk,
torvalds@linux-foundation.org, drepper@gmail.com,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] nextfd(2)
Date: Thu, 12 Apr 2012 12:11:24 +0100 [thread overview]
Message-ID: <20120412121124.64aee2f6@pyramind.ukuu.org.uk> (raw)
In-Reply-To: <CACVxJT_RRfW7HknkbA4+41L9hNMBHZNezKs1ifbv_qFx5eB0-w@mail.gmail.com>
On Thu, 12 Apr 2012 13:54:25 +0300
Alexey Dobriyan <adobriyan@gmail.com> wrote:
> On Sat, Apr 7, 2012 at 12:02 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> > On 04/06/2012 01:16 PM, Alexey Dobriyan wrote:
> >>
> >> closefrom(3) written via nextfd(2) loop is reliable and doesn't fail.
> >> closefrom(3) written via /proc/self/fd is reliable and can fail (including ENOMEM).
> >> closefrom(3) written via close(fd++) is unreliable.
> >>
> >
> > I call shenanigans on this. There is no reason to ENOMEM on the second
> > written using the fdwalk() implementation I already posted, for example.
>
> open("/proc/self/fd") can fail with ENOMEM.
Any syscall can fail with a process kill due to a stack extend on out of
memory in most configurations. That includes your nextfd stuff
This whole thing is getting stupid. "Perfection is the enemy of
success".
Your code will also fail when the cat pees on the computer, when the
power fails and when disk dies. I suspect that other than the cat these
are all more likely real world cases than your ENOMEM.
Alan
next prev parent reply other threads:[~2012-04-12 11:08 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-01 12:57 [PATCH] nextfd(2) Alexey Dobriyan
2012-04-01 13:58 ` Konstantin Khlebnikov
2012-04-01 21:30 ` Alexey Dobriyan
2012-04-02 0:09 ` Alan Cox
2012-04-02 8:38 ` Konstantin Khlebnikov
2012-04-02 9:26 ` Cyrill Gorcunov
2012-04-01 15:43 ` Eric Dumazet
2012-04-01 21:31 ` Alexey Dobriyan
2012-04-01 21:36 ` Alan Cox
2012-04-01 17:20 ` Linus Torvalds
2012-04-01 18:28 ` Valentin Nechayev
2012-04-01 21:33 ` Alexey Dobriyan
2012-04-01 19:21 ` Arnd Bergmann
2012-04-01 21:35 ` Alexey Dobriyan
2012-04-01 22:05 ` H. Peter Anvin
2012-04-04 12:13 ` Arnd Bergmann
2012-04-01 22:03 ` H. Peter Anvin
2012-04-01 22:13 ` H. Peter Anvin
2012-04-02 0:08 ` Alan Cox
2012-04-30 9:58 ` Valentin Nechayev
2012-04-02 1:19 ` Kyle Moffett
2012-04-02 1:37 ` H. Peter Anvin
2012-04-02 11:37 ` Ulrich Drepper
2012-04-06 9:54 ` Alexey Dobriyan
2012-04-06 15:27 ` Colin Walters
2012-04-06 16:14 ` H. Peter Anvin
2012-04-06 20:16 ` Alexey Dobriyan
2012-04-06 20:33 ` H. Peter Anvin
2012-04-06 21:02 ` H. Peter Anvin
2012-04-12 10:54 ` Alexey Dobriyan
2012-04-12 11:11 ` Alan Cox [this message]
2012-04-12 13:35 ` Alexey Dobriyan
2012-04-12 13:51 ` H. Peter Anvin
2012-04-12 19:21 ` Alexey Dobriyan
2012-04-12 14:09 ` Eric Dumazet
2012-04-06 16:23 ` H. Peter Anvin
2012-04-07 21:21 ` Ben Pfaff
2012-04-11 0:12 ` KOSAKI Motohiro
2012-04-11 0:09 ` KOSAKI Motohiro
2012-04-11 17:58 ` H. Peter Anvin
2012-04-11 18:04 ` Linus Torvalds
2012-04-11 18:11 ` H. Peter Anvin
2012-04-11 19:46 ` KOSAKI Motohiro
2012-04-11 19:49 ` H. Peter Anvin
2012-04-11 20:23 ` KOSAKI Motohiro
2012-04-11 20:32 ` H. Peter Anvin
2012-04-17 18:12 ` KOSAKI Motohiro
2012-04-11 18:00 ` H. Peter Anvin
2012-04-11 19:20 ` KOSAKI Motohiro
2012-04-11 19:22 ` H. Peter Anvin
2012-04-11 19:26 ` KOSAKI Motohiro
2012-04-11 19:28 ` H. Peter Anvin
2012-04-11 19:31 ` KOSAKI Motohiro
2012-04-11 19:32 ` H. Peter Anvin
2012-04-02 23:17 ` KOSAKI Motohiro
2012-04-02 23:56 ` H. Peter Anvin
2012-04-04 11:51 ` Ulrich Drepper
2012-04-04 16:38 ` KOSAKI Motohiro
2012-04-04 16:43 ` Ulrich Drepper
2012-04-04 17:07 ` KOSAKI Motohiro
2012-04-04 17:49 ` Ulrich Drepper
2012-04-04 18:08 ` KOSAKI Motohiro
2012-04-04 16:31 ` KOSAKI Motohiro
2012-04-04 17:10 ` Colin Walters
2012-04-04 17:25 ` Colin Walters
2012-04-04 23:35 ` KOSAKI Motohiro
2012-04-04 18:44 ` H. Peter Anvin
2012-04-03 19:21 ` Colin Walters
2012-04-04 3:01 ` Al Viro
2012-04-04 17:10 ` KOSAKI Motohiro
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=20120412121124.64aee2f6@pyramind.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=drepper@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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 NNTP newsgroup(s).