From mboxrd@z Thu Jan  1 00:00:00 1970
From: "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] nextfd(2)
Date: Fri, 06 Apr 2012 14:02:25 -0700
Message-ID: <4F7F59E1.2040009@zytor.com>
References: <20120401125741.GA7484@p183.telecom.by> <4F78D0BA.9040709@zytor.com> <CACVxJT_WJYjecpZMGkyUrbE5gNROX1tOfFAcD84-hoPsypxcFQ@mail.gmail.com> <4F7F1659.5090305@zytor.com> <20120406201601.GA3310@p183.telecom.by>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 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
To: Alexey Dobriyan <adobriyan@gmail.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20120406201601.GA3310@p183.telecom.by>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

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.

	-hpa