Received: by 10.192.165.156 with SMTP id m28csp1593007imm; Wed, 11 Apr 2018 23:25:49 -0700 (PDT) X-Google-Smtp-Source: AIpwx48euMQTxrHUbadfbR314uHrggDBGEnJfmfUHzpaVngaYZzCoPGJdVaonDvvsshZgnTvmEl9 X-Received: by 2002:a17:902:6103:: with SMTP id t3-v6mr8388983plj.76.1523514349867; Wed, 11 Apr 2018 23:25:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523514349; cv=none; d=google.com; s=arc-20160816; b=elUq+nPlmo6ZYioqSs92PDY0XSmtEdVf+hN1md2WkyoqgmkxnCQT0RNxk8NB7SbYJX XUti9OPqIHoBKpbufHk5cHYtTZ8+4YtSA4QGI+JDWvU22jUZpZlQ7M4FaiqWJGX0pvJP Zun570Ke1pqF/PNvnw6GoaPiQ113BHBQMXCyOdBKEd/xZwuQu5V2OwLEedt9fy1y0da9 cZpAk4Nr73OeLtQbMVfpl5ke/VQpQUUX362HWRNDC7EfqITnusFFLL2awl0BWDclpDzk GKMRgwuIYxVcldpTxbaO9WzNVqDAisc6+sUSIfH2OvmyvkANhpuCb/dnc/79/0vBEJMI HRrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=mQPYY2RH8f9YyEo5DbzsYRUdJgCPnEx0JzvrMttwsTE=; b=Ffcc8wDEU8leIcQyA56jjqAy94T+WerS/l7IUHs+jqEG2lIoZOYtRtf0OX7oIMLO7E ifzrDlJxbc6K9OHa8kSpyMhQon+zbG3Ajg2CbXEmK5XN/N/73/xto8mOdDewjLGZEBVx mD+x72+REToolqELpJ9aUrP1mcAv9+h1nkHmFsx5lUc/MLrTv+NK0/rWzSsAtG1M/BYh XyAVRTHWDlkWoUodme0dSSVBlaQtgBl1sBuTEZ6F1rPQKhvMWYOYM5zMIXYilTiU+3jf OS94GHIphcfRygPcr9mjYIvCsCL3IgRFHgTDOlees4Dfg0cTluIbnEE6hF0Irtd4Ju7n 9+9Q== 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 bf3-v6si2453732plb.643.2018.04.11.23.25.12; Wed, 11 Apr 2018 23:25:49 -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 S1752603AbeDLGWQ (ORCPT + 99 others); Thu, 12 Apr 2018 02:22:16 -0400 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:52876 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752501AbeDLGWP (ORCPT ); Thu, 12 Apr 2018 02:22:15 -0400 X-IronPort-AV: E=Sophos;i="5.48,440,1517871600"; d="scan'208";a="261752893" Received: from ip-146.net-89-2-7.rev.numericable.fr (HELO [192.168.0.15]) ([89.2.7.146]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2018 08:22:13 +0200 Date: Thu, 12 Apr 2018 08:22:12 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Joe Perches cc: Andrew Morton , Peter Zijlstra , "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 Subject: Re: [PATCH] checkpatch: Add a --strict test for structs with bool member definitions In-Reply-To: <1c9f185f6086e9d89659f93720a27b660ee17c13.camel@perches.com> Message-ID: 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> <1c9f185f6086e9d89659f93720a27b660ee17c13.camel@perches.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 11 Apr 2018, Joe Perches wrote: > (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. I got 12667. I'm not sure to understand the issue. Will using a bitfield help if there are no other bitfields in the structure? julia > > > 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. > >