From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966888AbdIZA6i (ORCPT ); Mon, 25 Sep 2017 20:58:38 -0400 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:38927 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965341AbdIZA6h (ORCPT ); Mon, 25 Sep 2017 20:58:37 -0400 X-Original-SENDERIP: 156.147.1.121 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Tue, 26 Sep 2017 09:58:21 +0900 From: Byungchul Park To: Peter Zijlstra Cc: tj@kernel.org, johannes.berg@intel.com, mingo@kernel.org, tglx@linutronix.de, oleg@redhat.com, david@fromorbit.com, linux-kernel@vger.kernel.org, kernel-team@lge.com Subject: Re: [PATCH 2/3] lockdep: Introduce lock_acquire_might() Message-ID: <20170926005820.GO5994@X58A-UD3R> References: <1504578554-4137-1-git-send-email-byungchul.park@lge.com> <1504578554-4137-3-git-send-email-byungchul.park@lge.com> <20170905072239.ggxalc2vrbpoyppr@hirez.programming.kicks-ass.net> <20170912003502.GF3240@X58A-UD3R> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170912003502.GF3240@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 Tue, Sep 12, 2017 at 09:35:02AM +0900, Byungchul Park wrote: > On Tue, Sep 05, 2017 at 09:22:39AM +0200, Peter Zijlstra wrote: > > On Tue, Sep 05, 2017 at 11:29:13AM +0900, Byungchul Park wrote: > > > From the point of view of crossrelease, we can never be aware of the > > > release context in advance, until we get to the lock_release(). > > > However, this way we cannot report deadlocks occured at the time. > > > > > > Sometimes, we want to report that kind of problems, taking a risk > > > generating false dependencies e.g. lock_acquire()s in workqueue code, > > > which inevitably generate false ones with all acquisitions in works. > > > > > > It would be better to provide another primitive, lock_acquire_might() > > > for that purpose so that lockdep internal can be aware of what users > > > expect and get chances to enhance to avoid false ones. > > > > > > The primitive should: > > > > > > 1. work as if it's trylock, since links between lock_acquire_might() > > > and later ones are only meaningful. Remind this should be used to > > > do what crossrelease commit does, in advance. > > > > > > 2. make acquisitions by lock_acquire_might() ignored on the commit. > > > > > > > Shees, talk about ugly... Also might-lock has a different meaning. > > OK. The description should be modified. I think I failed to explain what > I intended. What do you think about the following, which I saied in > another thread? > > If we use real acquisitions instead of 'might' for that speculative > purpose as the workqueue code currently does: > > (1) All locks used in every work->func() generate false dependencies > with 'work' lockdep_map and 'wq' lockdep_map, while any flush works > are not involved. But, it's inevitable. > > (2) Moreover, it also generates more false ones between the real > acquisitions. Of course, it can be avoidable if we force to use only > recursive-read for that purpose, which is not true for now. > > (3) Moreover, it also generates more false ones between holding locks > and the real ones. Of course, the workqueue code is not the case for > now. > > (4) Moreover, it also generates more false ones between the real ones > and a crosslock on commit, once crossrelease is able to work for > recursive-read things. Here, I want to discuss 'might' thing. IMHO, new primitive should be used instead of read-recursive on speculative acquisitons used in e.g. workqueue or smp/hotplug.