Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754564AbdIEXwp (ORCPT ); Tue, 5 Sep 2017 19:52:45 -0400 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:53978 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753611AbdIEXwn (ORCPT ); Tue, 5 Sep 2017 19:52:43 -0400 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Wed, 6 Sep 2017 08:52:35 +0900 From: Byungchul Park To: Peter Zijlstra Cc: Byungchul Park , Ingo Molnar , Tejun Heo , Boqun Feng , david@fromorbit.com, Johannes Berg , oleg@redhat.com, "linux-kernel@vger.kernel.org" , kernel-team@lge.com Subject: Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation Message-ID: <20170905235235.GZ3240@X58A-UD3R> References: <20170904013031.GM3240@X58A-UD3R> <20170904114248.kls4jv2ggsv46mli@hirez.programming.kicks-ass.net> <20170905003844.GO3240@X58A-UD3R> <20170905070825.tovfkqvxpwosh5oa@hirez.programming.kicks-ass.net> <20170905071930.h6t2f4guvmswibnv@hirez.programming.kicks-ass.net> <20170905085727.GV3240@X58A-UD3R> <20170905093624.zlwhvg32ahkpnamk@hirez.programming.kicks-ass.net> <20170905103144.GW3240@X58A-UD3R> <20170905105838.GX3240@X58A-UD3R> <20170905134643.mbjjphn2obwkzpzx@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170905134643.mbjjphn2obwkzpzx@hirez.programming.kicks-ass.net> 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 Content-Length: 1694 Lines: 36 On Tue, Sep 05, 2017 at 03:46:43PM +0200, Peter Zijlstra wrote: > On Tue, Sep 05, 2017 at 07:58:38PM +0900, Byungchul Park wrote: > > On Tue, Sep 05, 2017 at 07:31:44PM +0900, Byungchul Park wrote: > > > Recursive-read and the hint I proposed(a.k.a. might) should be used for > > > their different specific applications. Both meaning and constraints of > > > them are totally different. > > > > > > Using a right function semantically is more important than making it > > > just work, as you know. Wrong? > > > Of course, in the following cases, the results are same: > > > > recursive-read(A) -> recursive-read(A), is like nothing, and also > > might(A) -> might(A) , is like nothing. > > > > recursive-read(A) -> lock(A), end in a deadlock, and also > > might(A) -> lock(A), end in a deadlock. > > And these are exactly the cases we need. > > > Futhermore, recursive-read-might() can be used if needed, since their > > semantics are orthogonal so they can be used in mixed forms. > > > > I really hope you accept the new semantics... I think current workqueue > > code exactly needs the semantics. > > I really don't want to introduce this extra state if we don't have to. OK. If the workqueue is only user of the weird lockdep annotations, then it might be better to defer introducing the extra state until needed. But, the 'might' thing I introduced would be necessary if more users want to report deadlocks at the time for crosslocks with speculative acquisitions like the workqueue does, since the recursive-read thing would generate false dependencies much more than we want, while the 'might' thing generate them just as many as we want.