Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Feb 2010 17:29:44 +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:  <3bbf2fe11002080829l4d5bb55ue82e3ce5f65f2ae2@mail.gmail.com>
In-Reply-To: <20100208154158.GM9991@deviant.kiev.zoral.com.ua>
References:  <20100207160031.GA27434@muon.cran.org.uk> <201002080900.44745.jhb@freebsd.org> <20100208145354.GJ9991@deviant.kiev.zoral.com.ua> <3bbf2fe11002080701u35a3e419ke562735f4f00ce97@mail.gmail.com> <3bbf2fe11002080706k11275a9evbf8a7fa1b14b447f@mail.gmail.com> <20100208150818.GL9991@deviant.kiev.zoral.com.ua> <3bbf2fe11002080740q1da560c8r8c8d92a1053d021b@mail.gmail.com> <20100208154158.GM9991@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

2010/2/8 Kostik Belousov <kostikbel@gmail.com>:
> On Mon, Feb 08, 2010 at 04:40:29PM +0100, Attilio Rao wrote:
>> 2010/2/8 Kostik Belousov <kostikbel@gmail.com>:
>> > On Mon, Feb 08, 2010 at 04:06:56PM +0100, Attilio Rao wrote:
>> >> 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:
>> >> >>> >  1st 0xffffff00c51279f8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1204
>> >> >>> >  2nd 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 = 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.

Oh right, I readed recycle.

Attilio


-- 
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?3bbf2fe11002080829l4d5bb55ue82e3ce5f65f2ae2>