From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via pointer conversion) Date: Fri, 17 Nov 2006 09:24:06 -0500 Message-ID: <1163773446.13410.52.camel@dantu.rdu.redhat.com> References: <1163770980.13410.39.camel@dantu.rdu.redhat.com> <20061117135037.GB18567@parisc-linux.org> <20061117141445.GB9820@wohnheim.fh-wedel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Matthew Wilcox , linux-fsdevel@vger.kernel.org Return-path: Received: from mx1.redhat.com ([66.187.233.31]:18900 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S933617AbWKQOYI (ORCPT ); Fri, 17 Nov 2006 09:24:08 -0500 To: =?ISO-8859-1?Q?J=F6rn?= Engel In-Reply-To: <20061117141445.GB9820@wohnheim.fh-wedel.de> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 2006-11-17 at 15:14 +0100, J=C3=B6rn Engel wrote: > If you are talking about inode_init_once() here, I like the idea. > i_generation must be initialized somehow, even a 4-byte information > leak could be a problem. But the initialization should happen in the > rare event of allocating a slab page, not when reusing a deleted > inode. >=20 > Jeff, why do you increment i_generation in new_inode instead of here? I suppose we could do that...that might be better for stuff that calls alloc_inode directly. -- Jeff - 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