From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753248AbdJTT7D (ORCPT ); Fri, 20 Oct 2017 15:59:03 -0400 Received: from esa5.hgst.iphmx.com ([216.71.153.144]:3708 "EHLO esa5.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752581AbdJTT67 (ORCPT ); Fri, 20 Oct 2017 15:58:59 -0400 X-IronPort-AV: E=Sophos;i="5.43,408,1503331200"; d="scan'208";a="58947387" From: Bart Van Assche To: "tglx@linutronix.de" CC: "mingo@kernel.org" , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "hch@infradead.org" , "amir73il@gmail.com" , "linux-xfs@vger.kernel.org" , "linux-mm@kvack.org" , "linux-block@vger.kernel.org" , "oleg@redhat.com" , "darrick.wong@oracle.com" , "johannes.berg@intel.com" , "byungchul.park@lge.com" , "linux-fsdevel@vger.kernel.org" , "idryomov@gmail.com" , "tj@kernel.org" , "kernel-team@lge.com" , "david@fromorbit.com" Subject: Re: [RESEND PATCH 1/3] completion: Add support for initializing completion with lockdep_map Thread-Topic: [RESEND PATCH 1/3] completion: Add support for initializing completion with lockdep_map Thread-Index: AQHTR/T3eL1/ixvRQkSJ6yiAuin4s6Lr0sMAgAB4UQCAAOC2AA== Date: Fri, 20 Oct 2017 19:58:54 +0000 Message-ID: <1508529532.3029.15.camel@wdc.com> References: <1508319532-24655-1-git-send-email-byungchul.park@lge.com> <1508319532-24655-2-git-send-email-byungchul.park@lge.com> <1508455438.4542.4.camel@wdc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Bart.VanAssche@wdc.com; x-originating-ip: [63.163.107.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;CY1PR0401MB1534;20:nqx0HHFXbuDU1X/h7kzl7IN2zi6y4984/QG0zozFJtq7KncSY7ExOMWJC9t9QRmmpZoWuFA6sgtIP4KCjQ4AJ0Ku+bXXix1+CmxVTduuzeexzc64Y9NJdvxnWG22qyVPoWdprNgDPfHsQ33mV4NZWFc8ZRmWwBcMnxf0dehjkDs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 571432c0-bf17-491f-3623-08d517f4fe23 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(48565401081)(2017052603199);SRVR:CY1PR0401MB1534; x-ms-traffictypediagnostic: CY1PR0401MB1534: wdcipoutbound: EOP-TRUE x-exchange-antispam-report-test: UriScan:(20558992708506)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(3231020)(6055026)(6041248)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CY1PR0401MB1534;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1PR0401MB1534; x-forefront-prvs: 0466CA5A45 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(376002)(39860400002)(346002)(377424004)(24454002)(189002)(199003)(105586002)(72206003)(66066001)(50986999)(8936002)(2501003)(4326008)(229853002)(93886005)(6436002)(6486002)(6506006)(77096006)(305945005)(81156014)(7736002)(478600001)(14454004)(54356999)(101416001)(81166006)(8676002)(86362001)(76176999)(1730700003)(25786009)(2900100001)(3660700001)(2906002)(4001150100001)(6512007)(3280700002)(3846002)(6116002)(99286003)(2351001)(97736004)(2950100002)(54906003)(106356001)(7416002)(316002)(102836003)(39060400002)(5660300001)(5640700003)(68736007)(103116003)(6916009)(33646002)(189998001)(53936002)(36756003)(6246003)(217873001);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0401MB1534;H:CY1PR0401MB1536.namprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4A4A6AF3E3BC7E488C0D3A7B1918BEFE@namprd04.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: wdc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2017 19:58:54.4722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1534 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v9KJx8wu002108 On Fri, 2017-10-20 at 08:34 +0200, Thomas Gleixner wrote: > On Thu, 19 Oct 2017, Bart Van Assche wrote: > > Are there any completion objects for which the cross-release checking is > > useful? > > All of them by definition. Sorry but I'm not sure that's the best possible answer. In my opinion avoiding that completion objects have dependencies on other lock objects, e.g. by avoiding to wait on a completion object while holding a mutex, is a far superior strategy over adding cross-release checking to completion objects. The former strategy namely makes it unnecessary to add cross-release checking to completion objects because that strategy ensures that these completion objects cannot get involved in a deadlock. The latter strategy can lead to false positive deadlock reports by the lockdep code, something none of us wants. A possible alternative strategy could be to enable cross-release checking only for those completion objects for which waiting occurs inside a critical section. > > Are there any wait_for_completion() callers that hold a mutex or > > other locking object? > > Yes, there are also cross completion dependencies. There have been such > bugs and I expect more to be unearthed. > > I really have to ask what your motiviation is to fight the lockdep coverage > of synchronization objects tooth and nail? As explained in another e-mail thread, unlike the lock inversion checking performed by the <= v4.13 lockdep code, cross-release checking is a heuristic that does not have a sound theoretical basis. The lock validator is an important tool for kernel developers. It is important that it produces as few false positives as possible. Since the cross-release checks are enabled automatically when enabling lockdep, I think it is normal that I, as a kernel developer, care that the cross-release checks produce as few false positives as possible. Bart.