On Mon, Mar 23, 2020 at 09:33:42AM -0700, Darrick J. Wong wrote: > lockdep tracks the rwsem's lock state /and/ which process actually > holds the rwsem. This ownership doesn't transfer from 28177 to 27081, > so when the kworker asks lockdep if it holds ILOCK_EXCL, lockdep says > no, because 27081 doesn't own the lock, 28177 does. Kaboom. > The old mrlock_t had that 'int mr_writer' field which didn't care about > lock ownership and so isilocked would return true and so the assert was > happy. > > So now comes the fun part -- the old isilocked code had a glaring hole > in which it would return true if *anyone* held the lock, even if the > owner is some other unrelated thread. That's probably good enough for > most of the fstests because we generally only run one thread at a time, > and developers will probably notice. :) > > However, with your series applied, the isilocked function becomes much > more powerful when lockdep is active because now we can test that the > lock is held *by the caller*, which closes that hole. > > Unfortunately, it also trips over this bmap split case, so if there's a > way to solve that problem we'd better find it quickly. Unfortunately, I > don't know of a way to gift a lock to another thread temporarily... > > Thoughts? lock_release() in the donor, lock_acquire in the worker context, and vice versa on return. We already do that dance indirectly with xfs_setfilesize_trans_alloc and friends.
