From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751674AbdIENrB (ORCPT <rfc822;w@1wt.eu>);
        Tue, 5 Sep 2017 09:47:01 -0400
Received: from merlin.infradead.org ([205.233.59.134]:55072 "EHLO
        merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751002AbdIENq5 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 5 Sep 2017 09:46:57 -0400
Date: Tue, 5 Sep 2017 15:46:43 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Byungchul Park <byungchul.park@lge.com>
Cc: Byungchul Park <max.byungchul.park@gmail.com>,
        Ingo Molnar <mingo@kernel.org>, Tejun Heo <tj@kernel.org>,
        Boqun Feng <boqun.feng@gmail.com>, david@fromorbit.com,
        Johannes Berg <johannes@sipsolutions.net>, oleg@redhat.com,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        kernel-team@lge.com
Subject: Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
Message-ID: <20170905134643.mbjjphn2obwkzpzx@hirez.programming.kicks-ass.net>
References: <20170901163852.ckslrgldsalqmg3c@hirez.programming.kicks-ass.net>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170905105838.GX3240@X58A-UD3R>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.
And as you already noted, this 'might' thing of yours doesn't belong in
the .read argument, since as you say its orthogonal.

recursive-read
wait_for_completion()
			recursive-read
			complete()

is fundamentally not a deadlock, we don't need anything extra.