Subject: Re: [PATCH] NFS client has troubles with fileid with bit 31 (or
	bit 63) set
From: Frank Filz <ffilzlnx@us.ibm.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: ffilz@us.ibm.com, NFS List <linux-nfs@vger.kernel.org>
In-Reply-To: <1291259596.6609.109.camel@heimdal.trondhjem.org>
References: <1291251786.5075.6.camel@KPMH461.ibm.com>
	 <1291253786.6609.90.camel@heimdal.trondhjem.org>
	 <1291258912.5075.10.camel@KPMH461.ibm.com>
	 <1291259596.6609.109.camel@heimdal.trondhjem.org>
Content-Type: text/plain
Date: Thu, 02 Dec 2010 09:44:50 -0800
Message-Id: <1291311890.5075.23.camel@KPMH461.ibm.com>
Sender: linux-nfs-owner@vger.kernel.org
MIME-Version: 1.0


On Wed, 2010-12-01 at 22:13 -0500, Trond Myklebust wrote:
> I'm suggesting it should rather match the compat_ulong_t, since that is
> what 64-bit kernels will need to deal with if running a 32-bit
> userspace. For 64-bit kernels that have no 32-bit userspace emulation
> layer, why would we care about returning a truncated 32-bit fileid?
> 
> Conversely, if running a 32-bit kernel, then 'unsigned long' will
> directly match the types used by fs/readdir.c:filldir()

Ah, got it now... Sorry for denseness...

Hmm, what would be ideal is for nfs_compat_user_ino64() to know if it's
value will be passed to compat_filldir or filldir. If we use
compat_ulong_t when CONFIG_COMPAT is defined, and enable_ino64 = 0, it
will always reduce the fileid to 32 bits, even if being passed to
filldir on a 64 bit machine which is prepared to take a 64 bit fileid.
On the other hand, if enable_ino64 = 1, then fileids >= 2^32 will cause
an error if a 32 bit user space application is being invoked.

With enable_ino64 = 1 on a machine otherwise enabled for 64 bit inode
numbers, it will definitely work like any local file system with 64 bit
inode numebers.

With enable_ino64 = 0, it will always force fileid into 32 bits if there
is any 32 bit user space, which I suppose is good behavior.

I will submit a revised patch.

Thanks

Frank