From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753950AbdHWK1A (ORCPT ); Wed, 23 Aug 2017 06:27:00 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:58967 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753847AbdHWK06 (ORCPT ); Wed, 23 Aug 2017 06:26:58 -0400 Date: Wed, 23 Aug 2017 12:26:52 +0200 From: Peter Zijlstra To: Byungchul Park Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, kernel-team@lge.com, Arnaldo Carvalho de Melo , Dave Chinner , Tejun Heo , johannes@sipsolutions.net Subject: Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING Message-ID: <20170823102652.brnjitvcxqo7avyj@hirez.programming.kicks-ass.net> References: <1502960261-16206-1-git-send-email-byungchul.park@lge.com> <20170821154600.asyzqs2zg6w6o4pg@hirez.programming.kicks-ass.net> <20170822051438.GD20323@X58A-UD3R> <20170822075238.uyfmhgxeal2bwcdg@hirez.programming.kicks-ass.net> <20170822085100.GH20323@X58A-UD3R> <20170822092141.fjmr74xhfid7vu7h@hirez.programming.kicks-ass.net> <20170822093337.GJ20323@X58A-UD3R> <20170822100840.eababgjcu76iois5@hirez.programming.kicks-ass.net> <20170822134922.m2g6kqsqo2eojrg7@hirez.programming.kicks-ass.net> <20170823024323.GD3108@X58A-UD3R> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170823024323.GD3108@X58A-UD3R> 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 Wed, Aug 23, 2017 at 11:43:23AM +0900, Byungchul Park wrote: > On Tue, Aug 22, 2017 at 03:49:22PM +0200, Peter Zijlstra wrote: > > So I think we'll end up hitting a lockdep deficiency and not trigger the > > splat on flush_work(), see also: > > > > https://lwn.net/Articles/332801/ > > > > lock_map_acquire_read() is a read-recursive and will not in fact create > > any dependencies because of this issue. > > > > In specific, check_prev_add() has: > > > > if (next->read == 2 || prev->read == 2) > > return 1; > > > > This means that for: > > > > lock_map_acquire_read(W)(2) > > down_write(A) (0) > > > > down_write(A) (0) > > wait_for_completion(C) (0) > > > > lock_map_acquire_read(W)(2) > > complete(C) (0) > > > > All the (2) effectively go away and 'solve' our current issue, but: > > > > lock_map_acquire_read(W)(2) > > mutex_lock(A) (0) > > > > mutex_lock(A) (0) > > lock_map_acquire(W) (0) > > > > as per flush_work() will not in fact trigger anymore either. > > It should be triggered. Lockdep code should be fixed so that it does. Yeah, its just something we never got around to. Once every so often I get reminded of it, like now. But then it sits on the todo list and never quite happens.