> Date: Sat, 2 Jun 2018 15:08:14 -0700
> From: Philip Guenther <pguent...@proofpoint.com>
>
> On Sat, 2 Jun 2018, Christophe Prévotaux wrote:
> > This a witness report I got on boot with snapshot Jun 1st amd64
> >
> > root on sd0a (9b49e3196b9bfae8.a) swap on sd0b dump on sd0b
> > lock order reversal:
> > 1st 0xffffff021cdac180 vmmaplk (&map->lock) @
> > /usr/src/sys/uvm/uvm_map.c:4433
> > 2nd 0xffffff01dc5f71a8 inode (&ip->i_lock)
>
> I believe uvm and the vnode layer handle this correctly, with lock tries
> that fall back to releasing the other lock and retrying so progress is
> made. The fix for WITNESS complaining is to mark vmmaplk as a vnode lock.
>
> ok?
I don't think so. While we have UVM_FLAG_TRYLOCK, I don't think it is
used in the code paths shown in the original report.
This may still be a false positive though. Non-kernel maps will
experience different locking patterns and their locks should probably
be considered to be a different class than the lock associated with
the kernel map.
That said I think the kernel could end up mapping files into kernel
address space as well so I think this lock order reversal is real. A
way to avoid this is to change the pool allocator used for the
dirhash. The pool entries are smaller than a page, so I think
pool_allocator_single is the appropriate choice here.
Index: ufs/ufs/ufs_dirhash.c
===================================================================
RCS file: /cvs/src/sys/ufs/ufs/ufs_dirhash.c,v
retrieving revision 1.40
diff -u -p -r1.40 ufs_dirhash.c
--- ufs/ufs/ufs_dirhash.c 26 Oct 2017 02:38:54 -0000 1.40
+++ ufs/ufs/ufs_dirhash.c 3 Jun 2018 11:50:11 -0000
@@ -1053,7 +1053,7 @@ void
ufsdirhash_init(void)
{
pool_init(&ufsdirhash_pool, DH_NBLKOFF * sizeof(doff_t), 0, IPL_NONE,
- PR_WAITOK, "dirhash", NULL);
+ PR_WAITOK, "dirhash", &pool_allocator_single);
rw_init(&ufsdirhash_mtx, "dirhash_list");
arc4random_buf(&ufsdirhash_key, sizeof(ufsdirhash_key));
TAILQ_INIT(&ufsdirhash_list);
