NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/48135: Bad locking for umount

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

From: Michael van Elst <>
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,
 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.
                                 Michael van Elst
                                 "A potential Snark may lurk in every tree."

Home | Main Index | Thread Index | Old Index