From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S933960AbXCFGWr@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933960AbXCFGWr (ORCPT <rfc822;w@1wt.eu>);
	Tue, 6 Mar 2007 01:22:47 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933961AbXCFGWq
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 6 Mar 2007 01:22:46 -0500
Received: from gw1.cosmosbay.com ([86.65.150.130]:36880 "EHLO
	gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S933960AbXCFGWq (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 6 Mar 2007 01:22:46 -0500
Message-ID: <45ED08A9.9050501@cosmosbay.com>
Date: Tue, 06 Mar 2007 07:22:33 +0100
From: Eric Dumazet <dada1@cosmosbay.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Davide Libenzi <davidel@xmailserver.org>
CC: "H. Peter Anvin" <hpa@zytor.com>,
       Linus Torvalds <torvalds@linux-foundation.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [patch v2] epoll use a single inode ...
References: <Pine.LNX.4.64.0703051532590.4907@alien.or.mcafeemobile.com> <Pine.LNX.4.64.0703051558070.3998@woody.linux-foundation.org> <Pine.LNX.4.64.0703051609430.4907@alien.or.mcafeemobile.com> <Pine.LNX.4.64.0703051621590.3998@woody.linux-foundation.org> <45ECD122.6020907@zytor.com> <Pine.LNX.4.64.0703051832260.4907@alien.or.mcafeemobile.com> <45ECD3D4.5020305@zytor.com> <Pine.LNX.4.64.0703051841380.4907@alien.or.mcafeemobile.com>
In-Reply-To: <Pine.LNX.4.64.0703051841380.4907@alien.or.mcafeemobile.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [86.65.150.130]); Tue, 06 Mar 2007 07:22:41 +0100 (CET)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Davide Libenzi a écrit :
> On Mon, 5 Mar 2007, H. Peter Anvin wrote:
> 
>> Davide Libenzi wrote:
>>> Right now is using:
>>>
>>> 	this.len = sprintf(name, "[%u.%d]", current->pid, fd);
>>>
>>> That should be unique and not have the wraparound problem. Ack?
>>>
>> NAK, very much NAK.
>>
>> File descriptors aren't file structures, they're *pointers* to file
>> structures.
>>
>> It's perfectly possible -- downright common -- for a file descriptor to be
>> inherited by another process, and then the pid is recycled -- collision.
> 
> Ugh! Right! 64 bit counter it is ... :)

For epoll, I suspect this is harmless : Programs dont allocate epolls fd every 
milli second, but at startup only.

For pipes/sockets, using a 64 bits would be problematic, because sprintf() 
uses a divide for each digit. And a divide is slow. Ten divides are *very* slow.