On Sun, Jun 3, 2018 at 3:26 AM, Klemens Nanni <k...@openbsd.org> wrote:

> Snap from 31.05.2018 with
> OpenBSD 6.3-current (GENERIC.MP) #0: Sat Jun  2 16:21:22 CEST 2018
>     k...@x250.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> acquiring duplicate lock of same type: "&mp->mnt_lock"
> 1st vfslock @ /usr/src/sys/kern/vfs_subr.c:191
> 2nd vfslock @ /usr/src/sys/kern/vfs_subr.c:191
> Starting stack trace...
> witness_checkorder(9,ffffffff81ab15c8,bf,ffff800000d00040,21) at
> witness_checkorder+0x63d
> _rw_enter(0,1,0,ffff800000d00000) at _rw_enter+0x56
> vfs_stall(1,ffff800000025400) at vfs_stall+0xab

[Also reported by bluhm@ and others]

Is vfs_stall() the only place that locks (busies) multiple mounts?  If it's
the only place _and_ it hotlds no other locks when doing that then I think
it actually is safe, because it would be equivalent to multiple threads
each holding only a single mount lock and nothing else.

Even if we agree that evaluation is correct, I don't think we want to mark
mnt_lock as DUPOK for all purposes, but rather just pass LOP_DUPOK through
for the calls from vfs_stall().

Philip Guenther

Reply via email to