Re: kern/48135: Bad locking for umount

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

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

From: Michael van Elst <mlelstv%serpens.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/48135: Bad locking for umount
Date: Thu, 22 Aug 2013 20:05:28 +0200

 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."