From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932650AbdJJSO0 (ORCPT ); Tue, 10 Oct 2017 14:14:26 -0400 Received: from merlin.infradead.org ([205.233.59.134]:56444 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932114AbdJJSOX (ORCPT ); Tue, 10 Oct 2017 14:14:23 -0400 Date: Tue, 10 Oct 2017 20:14:09 +0200 From: Peter Zijlstra To: Linus Torvalds Cc: Byungchul Park , Fengguang Wu , Ingo Molnar , Linux Kernel Mailing List , LKP , Josh Poimboeuf , kernel-team@lge.com Subject: Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2 Message-ID: <20171010181409.74q7gxvahr7vkpia@hirez.programming.kicks-ass.net> References: <20171003140634.r2jzujgl62ox4uzh@wfg-t540p.sh.intel.com> <20171010054801.GD3323@X58A-UD3R> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============2250626824738234044==" MIME-Version: 1.0 From: Peter Zijlstra To: lkp@lists.01.org Subject: Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2 Date: Tue, 10 Oct 2017 20:14:09 +0200 Message-ID: <20171010181409.74q7gxvahr7vkpia@hirez.programming.kicks-ass.net> In-Reply-To: List-Id: --===============2250626824738234044== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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. --===============2250626824738234044==--