From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Sandeen Subject: Re: [PATCH] make last_inode counter in new_inode 32-bit on kernels that offer x86 compatability Date: Mon, 06 Nov 2006 15:36:56 -0600 Message-ID: <454FAAF8.8080707@redhat.com> References: <1162836725.6952.28.camel@dantu.rdu.redhat.com> <20061106182222.GO27140@parisc-linux.org> <1162838843.12129.8.camel@dantu.rdu.redhat.com> <20061106202313.GA691@wohnheim.fh-wedel.de> <454FA032.1070008@redhat.com> <20061106211134.GB691@wohnheim.fh-wedel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jeff Layton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: Received: from mx1.redhat.com ([66.187.233.31]:57048 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S1753834AbWKFVg6 (ORCPT ); Mon, 6 Nov 2006 16:36:58 -0500 To: =?ISO-8859-1?Q?J=F6rn_Engel?= In-Reply-To: <20061106211134.GB691@wohnheim.fh-wedel.de> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org J=F6rn Engel wrote: > On Mon, 6 November 2006 14:50:58 -0600, Eric Sandeen wrote: >>> While you're at it, how about making last_ino per-sb instead of >>> system-wide? ino collisions after a wrap are just as bad as inos >>> beyond 32bit. And this should be a fairly simple method to reduce = the >>> risk. >> Using a global counter for multiple filesystems should actually -red= uce- >> the chance of a collision on the same filesystem, since after you wr= ap the >> recycled number may go to a different filesystem. >=20 > You're missing something. The chance for a collision _per wrap_ is > reduced, as you said. But the number of wraps goes up. Overall and > for large numbers, the two effects compensate each other. Well, one concern is an intentional exploit. In which case "longer time" and "shorter time" don't matter -so- much. If it can happen at all, it's bad, period. OTOH if one filesystem (say, pipes) can wrap the numbers very quickly, while other spaces are otherwise more immune, then having it global put= s everything using it at a bit more risk. *shrug* I dunno, it's probably not worth arguing this point, it needs t= o be fixed properly in any case. :) -Eric - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html