Date: Mon, 8 Feb 2010 16:06:56 +0100 From: Attilio Rao <attilio@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: bzeeb+freebsd+lor@zabbadoz.net, Bruce Cran <bruce@cran.org.uk>, freebsd-current@freebsd.org Subject: Re: LOR: vfs_mount.c (ufs) / msdosfs_vfsops.c (devfs) Message-ID: <3bbf2fe11002080706k11275a9evbf8a7fa1b14b447f@mail.gmail.com> In-Reply-To: <3bbf2fe11002080701u35a3e419ke562735f4f00ce97@mail.gmail.com> References: <20100207160031.GA27434@muon.cran.org.uk> <201002080900.44745.jhb@freebsd.org> <20100208145354.GJ9991@deviant.kiev.zoral.com.ua> <3bbf2fe11002080701u35a3e419ke562735f4f00ce97@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2010/2/8 Attilio Rao <attilio@freebsd.org>: > 2010/2/8 Kostik Belousov <kostikbel@gmail.com>: >> On Mon, Feb 08, 2010 at 09:00:44AM -0500, John Baldwin wrote: >>> On Sunday 07 February 2010 11:00:32 am Bruce Cran wrote: >>> > Running -CURRENT from today, I unmounted the msdosfs filesystem on my >>> > phone and got the following LOR: >>> > >>> > lock order reversal: >>> > =C2=A01st 0xffffff00c51279f8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.= c:1204 >>> > =C2=A02nd 0xffffff010b892278 devfs (devfs) @ >>> > /usr/src/sys/modules/msdosfs/../../fs/msdosfs/msdosfs_vfsops.c:944 >>> > KDB: stack backtrace: >>> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >>> > _witness_debugger() at witness_debugger+0x2e >>> > witness_checkorder() at witness_checkorder+0x81e >>> > __lockmgr_args() at __lockmgr_args+0xd11 >>> > vop_stdlock() at vop_stdlock+0x39 >>> > VOP_LOCK1_APV() VOP_LOCK1_APV+0x9b >>> > _vn_lock() at _vn_lock+0x47 >>> > msdosfs_sync() at msdosfs_sync+0x227 >>> > dounmount() at dounmount+0x2ca >>> > unmount() at unmount+0x216 >>> > syscall() at syscall+0x2a2 >>> > Xfast_syscall() at Xfast_syscall+0xe1 >>> > --- syscall (22, FreeBSD ELF64, unmount), rip =3D 0x8006a1e3c, rsp = =3D >>> > 0x7fffffffe3a8, rbp =3D 0x800c08010 --- >>> >>> This is due to holding a lock on the coveredvp vnode for most of unmoun= t(2). >>> Probably it should not be held for all of that. =C2=A0Perhaps it is saf= e to just >>> keep the vnode referenced instead, or could the handling for coveredvp = just >>> move to the end of the function where it is now vput? >> >> Among other things, holding vnode lock on covered vnode prevents paralle= l >> unmounts of the same mount point. > > Uhm, I think that this should be hanlded by MNTK_UNMOUNT already (and > thus stopping forced unmounts too). In other words probabilly keeping coveredvnode held until MNTK_UNMOUNT and then refcounting it should be fine. Attilio --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe11002080706k11275a9evbf8a7fa1b14b447f>