Received: by 10.192.165.156 with SMTP id m28csp958867imm; Wed, 11 Apr 2018 09:54:52 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+OCQwpgby8zxb6f3hl3fAz9igfBEVGFCGYIze+LOhKXb59SBe8nocGqUC7u5hcxr7XJZX4 X-Received: by 10.98.76.68 with SMTP id z65mr4703237pfa.181.1523465692336; Wed, 11 Apr 2018 09:54:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523465692; cv=none; d=google.com; s=arc-20160816; b=i64egunA0ZdVT1R9d1M/PCCVz64Qghco75vYvJE8XwYJb8sUlXHibsoT2bX7aXGDCH 37swpslyCajqSpbWayo7575RP0r+3QWPBQb/rYNQksR62kekVA9AiJj3mtlOT2gnWMkp eJgbPVU1MFrlLhmshgB5N6XhsyW4auBMgbEp+hT7cz5x0oNBSNCsA2vQIxsb2x1MEG3h mZkFB+fj/mHQfxZSYEXJF2GNLL01qf9CgFYnkm1J4/zoPP4Vf6FMvIePUoMeHYVNPxm5 zhleaoKTkSDX6tII2YyWYF9BSr7ZAc7ORaUD6unyNM25VtYdTBPjOaI07yVfZma2pNcZ dfxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=opKvLhSrDIS1QpDCl8nwwPTKUESecvU+CnP9qWpKWhU=; b=laaxVSfPCPK4xjmPj8Anu9NoHi4k0Lfu6dNuNzwY45HHqt2un13TKz3hnGhCoT18N7 HJ9OE0dT/4wkaf87SZ/V+c/mGl5ICEnYFynm4syqC+qyb5VX9zwvauQYASi4WzTs4Boe cBkbP+Bw53ym7TiYMENPd2pvf0JQb4YUNu37+FC1Cj4uOS05OLMmzSOICxNzivqLox/Q m1GMfvn09fcsykct9UxwG9BPfKGwI2Is2VDTA6JplxF3yPNBzkhQ5aTE/kY9Y3OJJ10v nABzKpVtNqay2y3nAH+S2JXUaXfiABiKyHLa5ehFIig/AZsfDOqit9bHNjs6yuMRaf6B Qqig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d21-v6si1502879plr.352.2018.04.11.09.54.08; Wed, 11 Apr 2018 09:54:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753107AbeDKQvc (ORCPT + 99 others); Wed, 11 Apr 2018 12:51:32 -0400 Received: from smtprelay0217.hostedemail.com ([216.40.44.217]:48996 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751491AbeDKQva (ORCPT ); Wed, 11 Apr 2018 12:51:30 -0400 Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id D13F181B5194; Wed, 11 Apr 2018 16:51:29 +0000 (UTC) X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 50,0,0,,d41d8cd98f00b204,joe@perches.com,:::::::::::::::::::::::::::,RULES_HIT:41:355:379:541:599:967:968:973:982:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:2198:2199:2393:2525:2560:2563:2682:2685:2689:2693:2731:2828:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:5007:6119:6742:7903:9025:10004:10400:10450:10455:10848:11232:11658:11914:12043:12740:12760:12895:13069:13255:13311:13357:13439:14096:14097:14181:14659:14721:19904:19999:21080:21433:21627:21740:30012:30034:30054:30060:30070:30091,0,RBL:47.151.150.235:@perches.com:.lbl8.mailshell.net-62.8.0.100 64.201.201.201,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:20,LUA_SUMMARY:none X-HE-Tag: hat43_46edf0cea7818 X-Filterd-Recvd-Size: 3307 Received: from XPS-9350.home (unknown [47.151.150.235]) (Authenticated sender: joe@perches.com) by omf13.hostedemail.com (Postfix) with ESMTPA; Wed, 11 Apr 2018 16:51:27 +0000 (UTC) Message-ID: <1c9f185f6086e9d89659f93720a27b660ee17c13.camel@perches.com> Subject: Re: [PATCH] checkpatch: Add a --strict test for structs with bool member definitions From: Joe Perches To: Andrew Morton , Peter Zijlstra Cc: "Rafael J. Wysocki" , Andy Whitcroft , yuankuiz@codeaurora.org, Linux PM , "Rafael J. Wysocki" , Frederic Weisbecker , Thomas Gleixner , paulmck@linux.vnet.ibm.com, Ingo Molnar , Len Brown , Linux Kernel Mailing List , Julia Lawall Date: Wed, 11 Apr 2018 09:51:26 -0700 In-Reply-To: <20180411092959.e666ec443e4d3bb6f43901d7@linux-foundation.org> References: <891d4f632fbff5052e11f2d0b6fac35d@codeaurora.org> <20180410123305.GF4082@hirez.programming.kicks-ass.net> <95477c93db187bab6da8a8ba7c57836868446179.camel@perches.com> <20180410143950.4b8526073b4e3e34689f68cb@linux-foundation.org> <20180410150011.df9e036f57b5bcac7ac19686@linux-foundation.org> <20180411081502.GJ4082@hirez.programming.kicks-ass.net> <20180411092959.e666ec443e4d3bb6f43901d7@linux-foundation.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.28.0-4 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (Adding Julia Lawall) On Wed, 2018-04-11 at 09:29 -0700, Andrew Morton wrote: > We already have some 500 bools-in-structs I got at least triple that only in include/ so I expect there are at probably an order of magnitude more than 500 in the kernel. I suppose some cocci script could count the actual number of instances. A regex can not. > and the owners of that code will > be wondering whether they should change them, and whether they should > apply those remove-bool-in-struct patches which someone sent them. Which is why the warning is --strict only > So... can we please get some clarity here? > ... > > (ooh, https://lkml.org/lkml/2017/11/21/384 is working this morning) > > hm, Linus suggests that instead of using > > bool mybool; > > we should use > > unsigned mybool:1; > > However that introduces the risk that alterations of mybool will use > nonatomic rmw operations. > > unsigned myboolA:1; > unsigned myboolB:1; > > so > > foo->myboolA = 1; > > could scribble on concurrent alterations of foo->myboolB. I think. Without barriers, that could happen anyway. To me, the biggest problem with conversions from bool to bitfield is logical. ie: unsigned int.singlebitfield = 4; is not the same result as bool = 4; because of implicit truncation vs boolean conversion so a direct change of bool use in structs to unsigned would also require logic analysis.