On Mon, Feb 08, 2010 at 04:40:29PM +0100, Attilio Rao wrote: > 2010/2/8 Kostik Belousov <kostikbel_at_gmail.com>: > > On Mon, Feb 08, 2010 at 04:06:56PM +0100, Attilio Rao wrote: > >> 2010/2/8 Attilio Rao <attilio_at_freebsd.org>: > >> > 2010/2/8 Kostik Belousov <kostikbel_at_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: > >> >>> > š1st 0xffffff00c51279f8 ufs (ufs) _at_ /usr/src/sys/kern/vfs_mount.c:1204 > >> >>> > š2nd 0xffffff010b892278 devfs (devfs) _at_ > >> >>> > /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 = 0x8006a1e3c, rsp = > >> >>> > 0x7fffffffe3a8, rbp = 0x800c08010 --- > >> >>> > >> >>> This is due to holding a lock on the coveredvp vnode for most of unmount(2). > >> >>> Probably it should not be held for all of that. šPerhaps it is safe 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 parallel > >> >> 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. > > > > Actually, the coveredvp then might be reclaimed ? Failed unmount then > > cannot recover. > > I thought on domount() we did holdcount the coveredvp for the time being? > If we don't, maybe we should. Hold or ref does not prevent reclaim.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:00 UTC