[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/47040 (renaming mount point panics in namei)
The following reply was made to PR kern/47040; it has been noted by GNATS.
From: David Holland <dholland-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
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
Main Index |
Thread Index |