On 3/1/21 4:02 AM, Kalle Valo wrote:
Peter Zijlstra writes:
On Mon, Mar 01, 2021 at 10:45:32AM +0200, Kalle Valo wrote:
Peter Zijlstra writes:
On Fri, Feb 26, 2021 at 05:06:57PM -0700, Shuah Khan wrote:
Shuah Khan (3):
lockdep: add lockdep_assert_not_held()
lockdep: add lockdep lock
Peter Zijlstra writes:
> On Mon, Mar 01, 2021 at 10:45:32AM +0200, Kalle Valo wrote:
>> Peter Zijlstra writes:
>>
>> > On Fri, Feb 26, 2021 at 05:06:57PM -0700, Shuah Khan wrote:
>> >> Shuah Khan (3):
>> >> lockdep: add lockdep_assert_not_held()
>> >> lockdep: add lockdep lock state defines
On Mon, Mar 01, 2021 at 10:45:32AM +0200, Kalle Valo wrote:
> Peter Zijlstra writes:
>
> > On Fri, Feb 26, 2021 at 05:06:57PM -0700, Shuah Khan wrote:
> >> Shuah Khan (3):
> >> lockdep: add lockdep_assert_not_held()
> >> lockdep: add lockdep lock state defines
> >> ath10k: detect conf_mutex
Peter Zijlstra writes:
> On Fri, Feb 26, 2021 at 05:06:57PM -0700, Shuah Khan wrote:
>> Shuah Khan (3):
>> lockdep: add lockdep_assert_not_held()
>> lockdep: add lockdep lock state defines
>> ath10k: detect conf_mutex held ath10k_drain_tx() calls
>
> Thanks!
Via which tree should these go?
On Fri, Feb 26, 2021 at 05:06:57PM -0700, Shuah Khan wrote:
> Shuah Khan (3):
> lockdep: add lockdep_assert_not_held()
> lockdep: add lockdep lock state defines
> ath10k: detect conf_mutex held ath10k_drain_tx() calls
Thanks!
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 ke
