From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: NFS4 mount problem Date: Mon, 18 Apr 2005 11:34:10 +0100 Message-ID: <31006.1113820450@redhat.com> References: <1113766415.13680.79.camel@lade.trondhjem.org> <17895.1113566268@redhat.com> Cc: Linux Filesystem Development , Steve Dickson Return-path: Received: from mx1.redhat.com ([66.187.233.31]:13757 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S261401AbVDRKeU (ORCPT ); Mon, 18 Apr 2005 06:34:20 -0400 In-Reply-To: <1113766415.13680.79.camel@lade.trondhjem.org> To: Trond Myklebust Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Trond Myklebust wrote: > > 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. > > So, why is this not a case of "Doctor it hurts..."? Because: (1) The kernel is returning EFAULT to the 32-bit userspace; this implies that userspace is handing over a bad address. It isn't, the kernel is malfunctioning as it stands. (2) The kernel API does not prohibit 32-bit userspace calling mount() under a 64-bit kernel. All other filesystems cope with it (AFAIK), so NFS4 must too. Either the kernel should return ENOSYS for any 32-bit mount on a 64-bit kernel or it must support it fully. I think the latter is the right thing to do; despite what you'd prefer, there are other callers of the mount syscall out there. > There should therefore be exactly ONE instance of usage, and that is in > the "mount" program itself. Exactly. That should then be the ppc32 mount; which should work equally well with a ppc32 or a ppc64 kernel. David