From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4909873760786866470==" MIME-Version: 1.0 From: Byungchul Park To: lkp@lists.01.org Subject: Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2 Date: Wed, 11 Oct 2017 10:02:50 +0900 Message-ID: <20171011010250.GG3323@X58A-UD3R> In-Reply-To: <20171011005605.GF3323@X58A-UD3R> List-Id: --===============4909873760786866470== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Oct 11, 2017 at 09:56:05AM +0900, Byungchul Park wrote: > Thank you very much for explaining it in detail. > = > But let's shift a viewpoint. Precisely, I didn't want to work on locks > but *waiters* becasue dependancies causing deadlocks only can be created > by waiters - nevertheless I have no idea for a better name to my feature. > = > Lockdep should also have worked on waiters instead of locks, in the > strict sense. Having said that, we can work on locks to detect deadlocks > one way or another, becasue typical locks implicitly include wait > operations except trylocks, which in turn of course cause other waitings > once it's acquired successfully, though. > = > I mean, all we have to do to detect deadlocks is to identify > dependencies. *That's all*. IMHO, we don't need to consider "transfering > and recieving locks" and even lock protection. We only have to focus on ^ and owership. > dependecies by waiters and how to identify dependencies from them. > = > > This is kind of similar to my opinion on the C "volatile" keyword, and > > why we do not generally use it in the kernel. It's not the *data* that > > is volatile, because the data itself might be stable or volatile > > depending on whether you hold a lock or not. It's the _code_access_ > > that is either volatile or not, and rather than using volatile on data > > structures, we use volatile in code (although not explicitly as such - > > we hide it inside the accessors like "READ_ONCE()" etc). > = > I like it. I agree with you. > = > > I agree wholeheartedly that it can often be much more convenient to > > just mark one particular lock as being special, but at the same time > > it's really not the lock itself that is interesting, it's the > > _handoff_ of the lock that is interesting. > > = > > And particularly for cross-thread lock/unlock sequences, the hand-over > > really is special. For a normal lock/unlock sequence, the lock itself > > is the thing that protects the data. But that is simply not true if > > you have a cross-thread hand-over of the lock: you also need to make > > sure that the hand-over itself is safe. That's generally very easy to > > do, you just make sure that the original owner of the lock has done > > everything the lock protects and then make the lock available with > > smp_store_release() and then the receiving end should do > > smp_load_acquire() to read the lock pointer (or lock transfer status, > > or whatever). Because *within* a thread, memory ordering is guaranteed > > on its own. Between two threads? Memory ordering comes into play even > > when you *hold* the lock. > = > I and Peter have handled memory ordering carefully, when identifying > dependencies between waiters. That was where we have to consider memory > ordering. > = > Thanks, > Byungchul --===============4909873760786866470==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757221AbdJKBC6 (ORCPT ); Tue, 10 Oct 2017 21:02:58 -0400 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:43164 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756702AbdJKBCx (ORCPT ); Tue, 10 Oct 2017 21:02:53 -0400 X-Original-SENDERIP: 156.147.1.127 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Wed, 11 Oct 2017 10:02:50 +0900 From: Byungchul Park To: Linus Torvalds Cc: Fengguang Wu , Ingo Molnar , "Peter Zijlstra (Intel)" , 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: <20171011010250.GG3323@X58A-UD3R> References: <20171003140634.r2jzujgl62ox4uzh@wfg-t540p.sh.intel.com> <20171010054801.GD3323@X58A-UD3R> <20171011005605.GF3323@X58A-UD3R> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171011005605.GF3323@X58A-UD3R> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 11, 2017 at 09:56:05AM +0900, Byungchul Park wrote: > Thank you very much for explaining it in detail. > > But let's shift a viewpoint. Precisely, I didn't want to work on locks > but *waiters* becasue dependancies causing deadlocks only can be created > by waiters - nevertheless I have no idea for a better name to my feature. > > Lockdep should also have worked on waiters instead of locks, in the > strict sense. Having said that, we can work on locks to detect deadlocks > one way or another, becasue typical locks implicitly include wait > operations except trylocks, which in turn of course cause other waitings > once it's acquired successfully, though. > > I mean, all we have to do to detect deadlocks is to identify > dependencies. *That's all*. IMHO, we don't need to consider "transfering > and recieving locks" and even lock protection. We only have to focus on ^ and owership. > dependecies by waiters and how to identify dependencies from them. > > > This is kind of similar to my opinion on the C "volatile" keyword, and > > why we do not generally use it in the kernel. It's not the *data* that > > is volatile, because the data itself might be stable or volatile > > depending on whether you hold a lock or not. It's the _code_access_ > > that is either volatile or not, and rather than using volatile on data > > structures, we use volatile in code (although not explicitly as such - > > we hide it inside the accessors like "READ_ONCE()" etc). > > I like it. I agree with you. > > > I agree wholeheartedly that it can often be much more convenient to > > just mark one particular lock as being special, but at the same time > > it's really not the lock itself that is interesting, it's the > > _handoff_ of the lock that is interesting. > > > > And particularly for cross-thread lock/unlock sequences, the hand-over > > really is special. For a normal lock/unlock sequence, the lock itself > > is the thing that protects the data. But that is simply not true if > > you have a cross-thread hand-over of the lock: you also need to make > > sure that the hand-over itself is safe. That's generally very easy to > > do, you just make sure that the original owner of the lock has done > > everything the lock protects and then make the lock available with > > smp_store_release() and then the receiving end should do > > smp_load_acquire() to read the lock pointer (or lock transfer status, > > or whatever). Because *within* a thread, memory ordering is guaranteed > > on its own. Between two threads? Memory ordering comes into play even > > when you *hold* the lock. > > I and Peter have handled memory ordering carefully, when identifying > dependencies between waiters. That was where we have to consider memory > ordering. > > Thanks, > Byungchul