Avoid try_shrink_lock spinlock contention

Every lock_key_range call results in a spinlock on linfo->lock to do
housekeeping and reclaim idle locks. This housekeeping is non-critical
and can be deferred, but more importantly, while a reclaim pass is
ongoing, there's no need to attempt reclaim at the same time.

I ran into this while doing cross-node spam and it caused a near hard
lockup with my VM spinning on the lock for 7+ minutes, without making
any forward progress.

We can just trylock and give up. If the lock is held, another task
is already reclaiming and we're safe to skip. The force flag will
still cause a spin_lock to assure shutdown waits for other reclaims,
which needs to happen before shutdown can progress anyway.

Signed-off-by: Auke Kok <auke.kok@versity.com>

kmod/src/lock.c

@@ -906,7 +906,11 @@ static bool try_shrink_lock(struct super_block *sb, struct lock_info *linfo, boo
 	               READ_ONCE(linfo->nr_locks) <= opts.lock_idle_count))
 		return false;
 
-	spin_lock(&linfo->lock);
+	/* Shrinking is best-effort housekeeping unless forced. */
+	if (force)
+		spin_lock(&linfo->lock);
+	else if (!spin_trylock(&linfo->lock))
+		return false;
 
 	lock = list_first_entry_or_null(&linfo->lru_list, struct scoutfs_lock, lru_head);
 	if (lock && (force || (linfo->nr_locks > opts.lock_idle_count))) {