Re: [PATCH] NFS client has troubles with fileid with bit 31 (or bit 63) set

[Frank Filz <ffilzlnx@us.ibm.com>]

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