mbox series

[0/2] Add lockdep_assert_not_held()

Message ID cover.1613171185.git.skhan@linuxfoundation.org
Headers show
Series Add lockdep_assert_not_held() | expand

Message

Shuah Khan Feb. 12, 2021, 11:28 p.m. UTC 
Some kernel functions must not be called holding a specific lock. Doing
so could lead to locking problems. Currently these routines call
lock_is_held() to check for lock hold followed by WARN_ON.

Adding a common lockdep interface will help reduce the duplication of this
logic in the rest of the kernel.

Add lockdep_assert_not_held() to be used in these functions to detect
incorrect calls while holding a lock.

lockdep_assert_not_held() provides the opposite functionality of
lockdep_assert_held() which is used to assert calls that require
holding a specific lock.

The need for lockdep_assert_not_held() came up in a discussion on
ath10k patch. ath10k_drain_tx() and i915_vma_pin_ww() are examples
of functions that can use lockdep_assert_not_held().

Link: https://lore.kernel.org/linux-wireless/871rdmu9z9.fsf@codeaurora.org/

This patch series adds lockdep_assert_not_held() and uses it in the
second patch in ath10k_drain_tx() function.

Shuah Khan (2):
  lockdep: add lockdep_assert_not_held()
  ath10k: detect conf_mutex held ath10k_drain_tx() calls

 drivers/net/wireless/ath/ath10k/mac.c | 2 ++
 include/linux/lockdep.h               | 7 ++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

Comments

Kalle Valo Feb. 14, 2021, 6:08 a.m. UTC | #1 
Shuah Khan <skhan@linuxfoundation.org> writes:

> ath10k_drain_tx() must not be called with conf_mutex held as workers can

> use that also. Add call to lockdep_assert_not_held() on conf_mutex to

> detect if conf_mutex is held by the caller.

>

> The idea for this patch stemmed from coming across the comment block

> above the ath10k_drain_tx() while reviewing the conf_mutex holds during

> to debug the conf_mutex lock assert in ath10k_debug_fw_stats_request().

>

> Adding detection to assert on conf_mutex hold will help detect incorrect

> usages that could lead to locking problems when async worker routines try

> to call this routine.

>

> Link: https://lore.kernel.org/linux-wireless/871rdmu9z9.fsf@codeaurora.org/

> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>


This can go via the same tree as patch 1:

Acked-by: Kalle Valo <kvalo@codeaurora.org>


But I can also take this to my ath tree, once patch 1 has reached it.
Just let me know what is preferred.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches