On 2/15/21 9:10 AM, Johannes Berg wrote:
On Mon, 2021-02-15 at 17:04 +0100, Peter Zijlstra wrote:
On Mon, Feb 15, 2021 at 02:12:30PM +0100, Johannes Berg wrote:
On Mon, 2021-02-15 at 11:44 +0100, Peter Zijlstra wrote:
I think something like so will work, but please double check.
Yeah, that l
On Mon, 2021-02-15 at 17:04 +0100, Peter Zijlstra wrote:
> On Mon, Feb 15, 2021 at 02:12:30PM +0100, Johannes Berg wrote:
> > On Mon, 2021-02-15 at 11:44 +0100, Peter Zijlstra wrote:
> > > I think something like so will work, but please double check.
> >
> > Yeah, that looks better.
> >
> > > +++
On Mon, Feb 15, 2021 at 02:12:30PM +0100, Johannes Berg wrote:
> On Mon, 2021-02-15 at 11:44 +0100, Peter Zijlstra wrote:
> >
> > I think something like so will work, but please double check.
>
> Yeah, that looks better.
>
> > +++ b/include/linux/lockdep.h
> > @@ -294,11 +294,15 @@ extern void l
On Mon, 2021-02-15 at 11:44 +0100, Peter Zijlstra wrote:
>
> I think something like so will work, but please double check.
Yeah, that looks better.
> +++ b/include/linux/lockdep.h
> @@ -294,11 +294,15 @@ extern void lock_unpin_lock(struct lockdep_map *lock,
> struct pin_cookie);
>
> #define
On Sun, Feb 14, 2021 at 06:53:01PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 12, 2021 at 04:28:42PM -0700, Shuah Khan wrote:
>
> > +#define lockdep_assert_not_held(l) do {\
> > + WARN_ON(debug_locks && lockdep_is_held(l)); \
> > + } while (0)
> > +
>
> This th
On Fri, Feb 12, 2021 at 04:28:42PM -0700, Shuah Khan wrote:
> +#define lockdep_assert_not_held(l) do {\
> + WARN_ON(debug_locks && lockdep_is_held(l)); \
> + } while (0)
> +
This thing isn't as straight forward as you might think, but it'll
mostly work.
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
