From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932547AbdHWQjJ (ORCPT ); Wed, 23 Aug 2017 12:39:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40986 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932243AbdHWQjG (ORCPT ); Wed, 23 Aug 2017 12:39:06 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 71809C02C036 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=oleg@redhat.com Date: Wed, 23 Aug 2017 18:39:03 +0200 From: Oleg Nesterov To: Peter Zijlstra Cc: Byungchul Park , mingo@kernel.org, linux-kernel@vger.kernel.org, kernel-team@lge.com, Arnaldo Carvalho de Melo , Dave Chinner , Tejun Heo , johannes@sipsolutions.net Subject: Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING Message-ID: <20170823163903.GA12973@redhat.com> References: <1502960261-16206-1-git-send-email-byungchul.park@lge.com> <20170821154600.asyzqs2zg6w6o4pg@hirez.programming.kicks-ass.net> <20170822051438.GD20323@X58A-UD3R> <20170822075238.uyfmhgxeal2bwcdg@hirez.programming.kicks-ass.net> <20170822085100.GH20323@X58A-UD3R> <20170822092141.fjmr74xhfid7vu7h@hirez.programming.kicks-ass.net> <20170822093337.GJ20323@X58A-UD3R> <20170822100840.eababgjcu76iois5@hirez.programming.kicks-ass.net> <20170822134922.m2g6kqsqo2eojrg7@hirez.programming.kicks-ass.net> <20170822144602.uh5jzkkchvdgzs3s@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170822144602.uh5jzkkchvdgzs3s@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 23 Aug 2017 16:39:06 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter, I am all confused and I am still trying to understand your email. In particular, because I no longer understand the lockdep annotations in workqueue.c, it turns out I forgot everything... On 08/22, Peter Zijlstra wrote: > > I am however slightly puzzled by the need of flush_work() to take Q, > what deadlock potential is there? Do you really mean flush_work()? Or start_flush_work() ? > It was added by Oleg in commit: > > a67da70dc095 ("workqueues: lockdep annotations for flush_work()") No, these annotations were moved later into start_flush, iiuc... This lock_map_acquire(&work->lockdep_map); lock_map_release(&work->lockdep_map); was added by another commit 0976dfc1d0cd80a4e9dfaf87bd8744612bde475a "workqueue: Catch more locking problems with flush_work()", and at first glance it is fine. At the same time, I have a vague feeling that (perhaps) we can remove these 2 annotations if we change process_one_work() and start_flush_work(), not sure... Oleg.