Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752119AbdIAQjA (ORCPT ); Fri, 1 Sep 2017 12:39:00 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:40792 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751998AbdIAQi7 (ORCPT ); Fri, 1 Sep 2017 12:38:59 -0400 Date: Fri, 1 Sep 2017 18:38:52 +0200 From: Peter Zijlstra To: Byungchul Park 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: <20170901163852.ckslrgldsalqmg3c@hirez.programming.kicks-ass.net> References: <004701d32171$ce57d4c0$6b077e40$@lge.com> <20170830112546.GH3240@X58A-UD3R> <20170831080442.5vdgoaijzmrc776x@hirez.programming.kicks-ass.net> <20170831081501.GJ3240@X58A-UD3R> <20170831083453.5tfjofzk7idthsof@hirez.programming.kicks-ass.net> <20170901020512.GK3240@X58A-UD3R> <20170901094747.iv6s532ccuuzpry2@hirez.programming.kicks-ass.net> <20170901101629.GL3240@X58A-UD3R> <20170901123856.p2trpebau57yxftc@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1057 Lines: 27 On Fri, Sep 01, 2017 at 10:51:48PM +0900, Byungchul Park wrote: > On Fri, Sep 1, 2017 at 9:38 PM, Peter Zijlstra wrote: > > On Fri, Sep 01, 2017 at 07:16:29PM +0900, Byungchul Park wrote: > > > >> It would be gone _only_ at the time the history overrun, and then it > >> will be built again. So, you are wrong. > > s/it will be built again/the acquisition will be added into the xhlock > array again/ > > Now, better to understand? No, I still don't get it. How are we ever going to get the workqueue thread setup code back after its spooled out? > > How will it ever be build again? You only ever spawn the worker thread > > _ONCE_, then it runs lots and lots of works. > > > > We _could_ go fix it, but I really don't see it being worth the time and > > We don't need to fix it spending time and effort. Just *revert* all your > wrong patches. And get tangled up with the workqueue annotation again, no thanks. Having the first few works see the thread setup isn't worth it. And your work_id annotation had the same problem.