lkml.org 
[lkml]   [2015]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 13/14] lockdep: Implement lock pinning
On Fri, Jun 05, 2015 at 11:55:52AM +0200, Ingo Molnar wrote:
>
> * Peter Zijlstra <peterz@infradead.org> wrote:
>
> > RFC: a possible alternative API would be something like:
> >
> > int cookie = lockdep_pin_lock(&foo);
> > ...
> > lockdep_unpin_lock(&foo, cookie);
>
> Yeah, this would be even nicer.
>
> > Where we pick a random number for the pin_count; this makes it
> > impossible to sneak a lock break in without also passing the right
> > cookie along.
> >
> > I've not done this because it ends up generating code for !LOCKDEP,
> > esp. if you need to pass the cookie around for some reason.
>
> The cookie could be a zero-size structure, which can be 'passed around'
> syntactically but creates no overhead in the code.
>
> But I'd expect cookie-passing to be a sign of badness in most cases: the lock
> should generally be unpinned at the same level of abstraction...

I have tried to make this work, but so far I've failed at making the
!LOCKDEP case generate 'similar' code.

Esp, things like:

rq = task_rq_lock(p, flags);

...

task_rq_unlock(rq, p, flags);

Need to somehow pass the cookie, and all pure stack based approaches
I've tried ended up being ugly and generating weird code.

So I'll keep the non-cookie approach for now.


\
 
 \ /
  Last update: 2015-06-11 14:01    [W:0.065 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site