From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754675AbdJSPrI (ORCPT ); Thu, 19 Oct 2017 11:47:08 -0400 Received: from esa5.hgst.iphmx.com ([216.71.153.144]:8815 "EHLO esa5.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753943AbdJSPrG (ORCPT ); Thu, 19 Oct 2017 11:47:06 -0400 X-IronPort-AV: E=Sophos;i="5.43,402,1503331200"; d="scan'208";a="58748871" From: Bart Van Assche To: "tglx@linutronix.de" CC: "mingo@kernel.org" , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "linux-mm@kvack.org" , "byungchul.park@lge.com" , "kernel-team@lge.com" Subject: Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE Thread-Topic: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE Thread-Index: AQHTSJ7m0UDqA3q6tkapniLX+oGlRqLrRiaAgAAIIwCAAAN6gA== Date: Thu, 19 Oct 2017 15:47:03 +0000 Message-ID: <1508428021.2429.22.camel@wdc.com> References: <1508392531-11284-1-git-send-email-byungchul.park@lge.com> <1508392531-11284-3-git-send-email-byungchul.park@lge.com> <1508425527.2429.11.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;CY1PR0401MB1535;20:3GzA/qFVQZASTBMw8+ZyuXtuyzrXf/+etwqBHSqkatfeX/h3Lrpk8o8zbTCP2kveieqi/50jzRreuMqcIwPj8hxV4YiwdlTLKEwvy9mNAVtN7bDT4K+mk6xsbPpCu+rLncl3ed5SlUAbB/OR/vzM7N/9cjm4FlFgV44r/0ChCAs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 61cc463f-3096-4bb0-f945-08d51708a4e6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:CY1PR0401MB1535; x-ms-traffictypediagnostic: CY1PR0401MB1535: wdcipoutbound: EOP-TRUE x-exchange-antispam-report-test: UriScan:; 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)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CY1PR0401MB1535;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1PR0401MB1535; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(346002)(39860400002)(376002)(51444003)(189002)(377424004)(199003)(24454002)(189998001)(54906003)(6486002)(97736004)(77096006)(14454004)(2950100002)(229853002)(72206003)(6916009)(93886005)(2900100001)(6436002)(36756003)(2501003)(5640700003)(25786009)(6506006)(54356999)(76176999)(86362001)(4326008)(3660700001)(50986999)(6512007)(6246003)(99286003)(101416001)(53936002)(478600001)(8676002)(81156014)(1730700003)(81166006)(7736002)(102836003)(6116002)(2351001)(3846002)(3280700002)(8936002)(68736007)(2906002)(103116003)(305945005)(5660300001)(4001150100001)(316002)(66066001)(106356001)(105586002)(33646002);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0401MB1535;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: <39530C4220687A418C2E4D18327AB09C@namprd04.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: wdc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 15:47:03.5320 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1535 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 v9JFlDRE025432 On Thu, 2017-10-19 at 17:34 +0200, Thomas Gleixner wrote: > I really disagree with your reasoning completely > > 1) When lockdep was introduced more than ten years ago it was far from > perfect and we spent a reasonable amount of time to improve it, analyze > false positives and add the missing annotations all over the tree. That > was a process which took years. > > 2) Surely nobody is interested in wasting time on analyzing false > positives, but your (and other peoples) attidute of 'none of my > business' is what makes kernel development extremly frustrating. > > It should be in the interest of everybody involved in kernel development > to help with improving such features and not to lean back and wait for > others to bring it into a shape which allows you to use it as you see > fit. > > That's not how community works and lockdep would not be in the shape it is > today, if only a handful of people would have used and improved it. Such > things only work when used widely and when we get enough information so we > can address the weak spots. Hello Thomas, It seems like you are missing my point. Cross-release checking is really *broken* as a concept. It is impossible to improve it to the same reliability level as the kernel v4.13 lockdep code. Hence my request to make it possible to disable cross-release checking if PROVE_LOCKING is enabled. Consider the following example from the cross-release documentation: TASK X TASK Y ------ ------ acquire AX acquire B /* A dependency 'AX -> B' exists */ release B release AX held by Y My understanding is that the cross-release code will add (AX, B) to the lock order graph after having encountered the above code. I think that's wrong because if the following sequence (Y: acquire AX, X: acquire B, X: release B) is encountered again that there is no guarantee that AX can only be released by X. Any task other than X could release that synchronization object too. Bart.