All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Erez Zadok <ezk@cs.sunysb.edu>
Cc: linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Pavel Machek <pavel@ucw.cz>,
	Pavel Emelyanov <xemul@openvz.org>,
	"David S. Miller" <davem@davemloft.net>,
	Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [NFS] NFSv2/3 broken exporting/mounting (permission denied) in 2.6.24-rc4
Date: Fri, 7 Dec 2007 15:06:55 -0500	[thread overview]
Message-ID: <20071207200655.GD2204@fieldses.org> (raw)
In-Reply-To: <200712072000.lB7K0DZ5013256@agora.fsl.cs.sunysb.edu>

On Fri, Dec 07, 2007 at 03:00:13PM -0500, Erez Zadok wrote:
> In message <20071207025504.GA3070@fieldses.org>, "J. Bruce Fields" writes:
> > On Thu, Dec 06, 2007 at 09:20:41PM -0500, Erez Zadok wrote:
> > > I get a "permission denied" when trying to mount a localhost nfsv2/3
> > > exported volume, on v2.6.24-rc4-124-gf194d13.  It works w/ nfsv4 mounting.
> > > It worked fine in 2.6.24-rc3.  Here's a sequence of ops I tried:
> > > 
> > > # mount -t ext2 /dev/hdb1 /n/lower/b0
> > > # exportfs -o no_root_squash,rw localhost:/n/lower/b0
> > > # mount -t nfs -o nfsvers=3 localhost:/n/lower/b0 /mnt
> > 
> > What do you see if you watch the network traffic in ethereal?
> > 
> > --b.
> 
> Bruce, I'm using nfs-utils-1.0.10-14.fc6 on an FC6 system with all latest
> FC6 patches.  Using git-bisect I was able to find the patch which broke it:

Wow, thanks for your work finding that.

> 
> commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
> Author: Eric W. Biederman <ebiederm@xmission.com>
> Date:   Sun Dec 2 00:33:17 2007 +1100
> 
>     [NETNS]: Fix /proc/net breakage
>     
>     Well I clearly goofed when I added the initial network namespace support
>     for /proc/net.  Currently things work but there are odd details visible to
>     user space, even when we have a single network namespace.
>     
>     Since we do not cache proc_dir_entry dentries at the moment we can just
>     modify ->lookup to return a different directory inode depending on the
>     network namespace of the process looking at /proc/net, replacing the
>     current technique of using a magic and fragile follow_link method.
>     
>     To accomplish that this patch:
>     - introduces a shadow_proc method to allow different dentries to
>       be returned from proc_lookup.
>     - Removes the old /proc/net follow_link magic
>     - Fixes a weakness in our not caching of proc generic dentries.
>     
>     As shadow_proc uses a task struct to decided which dentry to return we can
>     go back later and fix the proc generic caching without modifying any code
>     that uses the shadow_proc method.
>     
>     Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>     Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
>     Cc: Pavel Machek <pavel@ucw.cz>
>     Cc: Pavel Emelyanov <xemul@openvz.org>
>     Cc: "David S. Miller" <davem@davemloft.net>
>     Cc: Ingo Molnar <mingo@elte.hu>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>     Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> With the above patch, rpc.mountd is unable to open /proc/fs/nfsd/filehandle.
> Strace shows:
> 
> open("/proc/fs/nfsd/filehandle", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)
> 
> Without the above patch, /proc/fs/nfsd is populated with a number of files,
> including "filehandle".

Those files are actually in a separate filesystem (of type "nfsd") which
is supposed to be mounted on /proc/fs/nfsd/.   So that mount must have
failed in the bad case?  It's not immediately obvious to me what this
patch has to do with that.  Hm.

--b.

  reply	other threads:[~2007-12-07 20:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-07  2:20 NFSv2/3 broken exporting/mounting (permission denied) in 2.6.24-rc4 Erez Zadok
2007-12-07  2:55 ` [NFS] " J. Bruce Fields
2007-12-07 20:00   ` Erez Zadok
2007-12-07 20:06     ` J. Bruce Fields [this message]
2007-12-07 20:32       ` Erez Zadok
2007-12-07 20:32         ` Erez Zadok
2007-12-07 20:38       ` Valdis.Kletnieks
2007-12-07 20:38       ` Valdis.Kletnieks
     [not found]     ` <200712072000.lB7K0DZ5013256-zop+azHP2WsZjdeEBZXbMidm6ipF23ct@public.gmane.org>
2007-12-07 20:06       ` J. Bruce Fields
2007-12-07 20:00   ` Erez Zadok
2007-12-07 20:05   ` Erez Zadok
2007-12-07 20:05   ` Erez Zadok
     [not found] ` <200712070220.lB72Kfqw004530-zop+azHP2WsZjdeEBZXbMidm6ipF23ct@public.gmane.org>
2007-12-07  2:55   ` J. Bruce Fields
  -- strict thread matches above, loose matches on Subject: below --
2007-12-07 10:54 Mikael Pettersson
     [not found] ` <200712071054.lB7AscVW002471-gq7oiAaKCbRt3AgVzhmPzw@public.gmane.org>
2007-12-07 15:32   ` J. Bruce Fields
2007-12-07  2:20 Erez Zadok

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071207200655.GD2204@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=ezk@cs.sunysb.edu \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nfs@lists.sourceforge.net \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    --cc=xemul@openvz.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.