We've come across an interesting problem with NFS4 mount on a PPC64 box. If
the mount program is compiled as PPC32, then the mount() syscall is returned
EFAULT.
It turns out that NFS4 requires potentially more data than can be put in a
single page, something sys_mount() enforces as a hard limit. This being the
case, nfs4_get_sb() expects the mount data to contain auxilliary pointers.
Unfortunately, the PPC32 userspace inserts 32-bit pointers, whilst the PPC64
kernel expects 64-bit pointers...
I can think of several ways to deal with this:
(1) Provide a PPC32 mount on ppc32 and a PPC64 mount on ppc64, and require
that these not be mixed.
This is something we'd like to avoid since we can otherwise run almost
entirely with a ppc32 userspace on a ppc64 kernel, making installation
less complex.
(2) Have the PPC32 mount program detect the fact that it's running under a
64-bit kernel and doctor the nfs4 mount data appropriately.
(3) Have the PPC32 mount program run the PPC64 mount program if it detects a
64-bit kernel.
(4) Have the ppc64 kernel detect whether it's a 32-bit or a 64-bit userspace
and translate the NFS4 mount() syscall if necessary.
(5) Introduce a new variation on the mount() syscall that can take more than
a page of data.
I would prefer option (4), otherwise we have to find _all_ usages of the
mount() system calls and fix them.
This has the potential to affect other places where we can run 32-bit
userspace under 64-bit kernels: i386 under x86_64 and s390 under s390x for
example.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
