[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120412121124.64aee2f6@pyramind.ukuu.org.uk>
Date: Thu, 12 Apr 2012 12:11:24 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: "H. Peter Anvin" <hpa@...or.com>, akpm@...ux-foundation.org,
viro@...iv.linux.org.uk, torvalds@...ux-foundation.org,
drepper@...il.com, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] nextfd(2)
On Thu, 12 Apr 2012 13:54:25 +0300
Alexey Dobriyan <adobriyan@...il.com> wrote:
> On Sat, Apr 7, 2012 at 12:02 AM, H. Peter Anvin <hpa@...or.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists