[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Oct 2017 20:14:09 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Byungchul Park <byungchul.park@....com>,
Fengguang Wu <fengguang.wu@...el.com>,
Ingo Molnar <mingo@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
LKP <lkp@...org>, Josh Poimboeuf <jpoimboe@...hat.com>,
kernel-team@....com
Subject: Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer
dereference at 000001f2
On Tue, Oct 10, 2017 at 09:56:26AM -0700, Linus Torvalds wrote:
> So I think the best model would be something like this:
>
> - T1:
> mutex_lock(&lock)
> ...
> mutex_transfer(&lock)
>
> - T2:
> mutex_receive(&lock);
> ...
> mutex_unlock(&lock);
>
> where the "mutex_transfer() -> mutex_receive()" thing really makes it
> obvious that "now thread 1 is transferring the lock to thread 2".
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.
Powered by blists - more mailing lists