From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?SsO2cm4=?= Engel Subject: Re: [RFC 2/7] cramfs: create unique inode numbers Date: Mon, 2 Jun 2008 07:42:49 +0200 Message-ID: <20080602054240.GA19219@logfs.org> References: <20080531152013.031903990@arndb.de> <20080531153510.692084580@arndb.de> <20080601165048.GC13094@logfs.org> <200806012324.51734.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, hch@lst.de To: Arnd Bergmann Return-path: Received: from lazybastard.de ([212.112.238.170]:56068 "EHLO longford.logfs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751495AbYFBFnV (ORCPT ); Mon, 2 Jun 2008 01:43:21 -0400 Content-Disposition: inline In-Reply-To: <200806012324.51734.arnd@arndb.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, 1 June 2008 23:24:51 +0200, Arnd Bergmann wrote: > On Sunday 01 June 2008, J=C3=B6rn Engel wrote: > >=20 > > Couldn't this cause problems for NFS? The same inode no longer has= a > > stable inode number across reboots. Basing on dentry location can = also > > be an information leak and cause problems on 64bit machines with ol= d > > userspace. >=20 > Sorry if I was not clear with this: I meant dentry location on disk, > not in memory. So the inode number is still stable across reboots and > does not leak data, it is just different from before. In that case I'd better retract my whole comment. ;) J=C3=B6rn --=20 All art is but imitation of nature. -- Lucius Annaeus Seneca -- 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