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 S1751016AbdHaIfA (ORCPT <rfc822;w@1wt.eu>);
        Thu, 31 Aug 2017 04:35:00 -0400
Received: from bombadil.infradead.org ([65.50.211.133]:52977 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750908AbdHaIe6 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 31 Aug 2017 04:34:58 -0400
Date: Thu, 31 Aug 2017 10:34:53 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Byungchul Park <byungchul.park@lge.com>
Cc: mingo@kernel.org, tj@kernel.org, boqun.feng@gmail.com,
        david@fromorbit.com, johannes@sipsolutions.net, oleg@redhat.com,
        linux-kernel@vger.kernel.org, kernel-team@lge.com
Subject: Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
Message-ID: <20170831083453.5tfjofzk7idthsof@hirez.programming.kicks-ass.net>
References: <20170829085939.ggmb6xiohw67micb@hirez.programming.kicks-ass.net>
 <20170830020953.GE3240@X58A-UD3R>
 <20170830074117.GG3240@X58A-UD3R>
 <20170830085333.GM32112@worktop.programming.kicks-ass.net>
 <004601d3216e$a3702030$ea506090$@lge.com>
 <20170830091223.xxnh3podtcumlabm@hirez.programming.kicks-ass.net>
 <004701d32171$ce57d4c0$6b077e40$@lge.com>
 <20170830112546.GH3240@X58A-UD3R>
 <20170831080442.5vdgoaijzmrc776x@hirez.programming.kicks-ass.net>
 <20170831081501.GJ3240@X58A-UD3R>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170831081501.GJ3240@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 Thu, Aug 31, 2017 at 05:15:01PM +0900, Byungchul Park wrote:
> It's not important. Ok, check the following, instead:
> 
> context X                 context Y
> ---------                 ---------
>                           wait_for_completion(C)
> acquire(A)
> release(A)
> process_one_work()
>    acquire(B)
>    release(B)
>    work->fn()
>       complete(C)
> 
> We don't need to lose C->A and C->B dependencies unnecessarily.

I really can't be arsed about them. Its really only the first few works
that will retain that dependency anyway, even if you were to retain
them.

All of that is contained in kernel/kthread and kernel/workqueue and can
be audited if needed. Its a very limited amount of code.