Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933870AbdHYPta (ORCPT ); Fri, 25 Aug 2017 11:49:30 -0400 Received: from mail-lf0-f46.google.com ([209.85.215.46]:35910 "EHLO mail-lf0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933662AbdHYPt3 (ORCPT ); Fri, 25 Aug 2017 11:49:29 -0400 MIME-Version: 1.0 In-Reply-To: <20170825133442.GU491396@devbig577.frc2.facebook.com> References: <1503650463-14582-1-git-send-email-byungchul.park@lge.com> <20170825133442.GU491396@devbig577.frc2.facebook.com> From: Byungchul Park Date: Sat, 26 Aug 2017 00:49:26 +0900 Message-ID: Subject: Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks To: Tejun Heo Cc: Byungchul Park , johannes.berg@intel.com, Peter Zijlstra , Ingo Molnar , tglx@linutronix.de, "linux-kernel@vger.kernel.org" , kernel-team@lge.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1657 Lines: 43 On Fri, Aug 25, 2017 at 10:34 PM, Tejun Heo wrote: > On Fri, Aug 25, 2017 at 05:41:03PM +0900, Byungchul Park wrote: >> Hello all, >> >> This is _RFC_. >> >> I want to request for comments about if it's reasonable conceptually. If >> yes, I want to resend after working it more carefully. >> >> Could you let me know your opinions about this? >> >> ----->8----- >> From 448360c343477fff63df766544eec4620657a59e Mon Sep 17 00:00:00 2001 >> From: Byungchul Park >> Date: Fri, 25 Aug 2017 17:35:07 +0900 >> Subject: [RFC] workqueue: remove manual lockdep uses to detect deadlocks >> >> We introduced the following commit to detect deadlocks caused by >> wait_for_completion() in flush_{workqueue, work}() and other locks. But >> now LOCKDEP_COMPLETIONS is introduced, such works are automatically done >> by LOCKDEP_COMPLETIONS. So it doesn't have to be done manually anymore. >> Removed it. > > I'm not following lockdep development, so can't really comment but if > you're saying that wq can retain the same level of protection while > not having explicit annotations, conceptually, it's of course great. Well.. I don't think it's the same level currently. But, I can make it with some modification. I expect the wq code to become much simpler. > However, how would it distinguish things like flushing another work I think it must be distinguished with what it actually waits for, e.i. completion variables instead of work or wq. I will make it next week and let you know. > item on a workqueue w/ max_active of 1? I will answer it wrt max_active == 1 next week. I need to review wq code. -- Thanks, Byungchul