Commit 3f5f6321 authored by Or Har-Toov's avatar Or Har-Toov Committed by Leon Romanovsky
Browse files

IB/core: Annotate umem_mutex acquisition under fs_reclaim for lockdep



Following the fix in the previous commit ("IB/mlx5: Fix potential
deadlock in MR deregistration"), teach lockdep explicitly about the
locking order between fs_reclaim and umem_mutex.

The previous commit resolved a potential deadlock scenario where
kzalloc(GFP_KERNEL) was called while holding umem_mutex, which could
lead to reclaim and eventually invoke the MMU notifier
(mlx5_ib_invalidate_range()), causing a recursive acquisition of
umem_mutex.

To prevent such issues from reoccurring unnoticed in future code
changes, add a lockdep annotation in ib_init_umem_odp() that simulates
taking umem_mutex inside a reclaim context. This makes lockdep aware
of this locking dependency and ensures that future violations—such as
calling kzalloc() or any memory allocator that may enter reclaim while
holding umem_mutex—will immediately raise a lockdep warning.

Signed-off-by: default avatarOr Har-Toov <ohartoov@nvidia.com>
Reviewed-by: default avatarMichael Guralnik <michaelgur@nvidia.com>
Link: https://patch.msgid.link/9d31b9d8fe1db648a9f47cec3df6b8463319dee5.1750061698.git.leon@kernel.org


Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
parent 2ed25aa7
Loading
Loading
Loading
Loading
+11 −0
Original line number Diff line number Diff line
@@ -76,6 +76,17 @@ static int ib_init_umem_odp(struct ib_umem_odp *umem_odp,
	end = ALIGN(end, page_size);
	if (unlikely(end < page_size))
		return -EOVERFLOW;
	/*
	 * The mmu notifier can be called within reclaim contexts and takes the
	 * umem_mutex. This is rare to trigger in testing, teach lockdep about
	 * it.
	 */
	if (IS_ENABLED(CONFIG_LOCKDEP)) {
		fs_reclaim_acquire(GFP_KERNEL);
		mutex_lock(&umem_odp->umem_mutex);
		mutex_unlock(&umem_odp->umem_mutex);
		fs_reclaim_release(GFP_KERNEL);
	}

	nr_entries = (end - start) >> PAGE_SHIFT;
	if (!(nr_entries * PAGE_SIZE / page_size))