Re: kern/47040 (renaming mount point panics in namei)

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/47040; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: Taylor R Campbell <campbell+netbsd%mumble.net@localhost>
Subject: Re: kern/47040 (renaming mount point panics in namei)
Date: Mon, 5 Nov 2012 00:01:35 +0000

 On Thu, Oct 11, 2012 at 12:45:03AM +0000, Taylor R Campbell wrote:
  >  No longer seems to panic, although EROFS (when the nullfs is mounted
  >  read-only) and ENOENT (when it is mounted read-write) seem like the
  >  wrong error codes.  Surely this should give EBUSY or something, no?
 
 Yes, it should.
 
 There isn't any useful way to circumvent EROFS until we have
 lookparent and vfs-level rename using it. However, the ENOENT is
 baloney and arises as follows:
 
   1. looking up bar/current.ro looks in bar (ffs) and gets the
      underlying mounted-on directory current.ro.
   2. lookup_once finds that this directory is mounted on, and crosses
      the mount point, to get the visible current.ro vnode, the root of
      the nullfs.
   3. doing this sets searchdir = foundobj, which is bogus.
   4. rename then gets back the nullfs root as both fdvp and fvp.
   5. rename then tries to use the nullfs root to relookup "current.ro",
      and since it isn't there we get ENOENT.
 
 If it *is* there, we'll probably get EXDEV.
 
 I thought the searchdir = foundobj was necessary (there is similar
 nonsense elsewhere that *is* necessary), but it turns out to have been
 introduced by yamt when he added the "avoid locking vnodes from two
 filesystems" logic in -r1.190, and it's wrong. The right thing to do
 in that case is to set searchdir = NULL.
 
 So most of -r1.190 should be reverted; however, clearing searchdir
 there requires some additional null checks (both in lookup_once and in
 the callers) and there's an annoying family of corner cases involving
 mounted volumes whose root vnodes are relative symlinks, so I don't
 think I'm going to get this done right away.
 
 With those we should get EBUSY again, though.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost