Re: kern/48135: Bad locking for umount

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Thu, Aug 22, 2013 at 07:42:37PM +0200, Michael van Elst wrote:

> >  Btw.: I'm not able to reproduce this error here -- what exactly is
> >        your setup (amd configuration etc.)

Here is another outcome of the race:

panic: lockdebug_lookup: uninitialized lock (lock=0xfffffe81e66d3050,
from=ffffffff8037e429)

breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x136
printf_nolog() at netbsd:printf_nolog
lockdebug_abort() at netbsd:lockdebug_abort+0xb0
mutex_exit() at netbsd:mutex_exit+0xaa
vfs_busy() at netbsd:vfs_busy+0xcb
lookup_once() at netbsd:lookup_once+0x14b
namei_tryemulroot() at netbsd:namei_tryemulroot+0x457
namei() at netbsd:namei+0x2b
fd_nameiat.clone.0() at netbsd:fd_nameiat.clone.0+0x54
do_sys_statat() at netbsd:do_sys_statat+0x84
sys___lstat50() at netbsd:sys___lstat50+0x2a
syscall() at netbsd:syscall+0x94

a previous doumount completed, called vfs_destroy() and lets vfs_busy()
continue and access the freed mutex.

It's obvious that you need a lock outside the mount structure to
arbitrate this. But I'm still wondering how VFS_UMOUNT can succeed
when namei uses vnodes that reference the mount when calling vfs_busy.


Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."