lkml.org 
[lkml]   [2017]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2
On Tue, Oct 10, 2017 at 11:14 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>
> Ah, but that's not at all what cross-release is about. Nobody really
> does wonky ownership transfer of mutexes like that (although there might
> be someone doing something with semaphores, I didn't check). Its to
> allow detecting this deadlock:
>
> mutex_lock(&lock)
> wait_for_completion(&c);
> mutex_lock(&lock);
> complete(&c);
>
> The completion doesn't have an owner to transfer.

Well, it really does. The "init_completion()" would be the original
owner (essentially the same as a "lock()"), then it has a transfer,
and then a receive, and then "complete()" is basically the unlock
elsewhere.

Of course, right now that transfer and receive is entirely implicit,
so you don't really see it anywhere. And for completions, the whole
_point_ is that transfer, so ..

The "wait_for_completion()" is then a normal lock operation (no
transfer there - it's just trying to get the lock again).

Linus

\
 
 \ /
  Last update: 2017-10-10 20:40    [W:0.084 / U:0.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site