linux-kernel - Re: [PATCH] checkpatch: Add a --strict test for structs with bool member definitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 11 Apr 2018 09:51:26 -0700
From:   Joe Perches <joe@...ches.com>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Andy Whitcroft <apw@...onical.com>, yuankuiz@...eaurora.org,
        Linux PM <linux-pm@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Frederic Weisbecker <fweisbec@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        paulmck@...ux.vnet.ibm.com, Ingo Molnar <mingo@...nel.org>,
        Len Brown <len.brown@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Julia Lawall <julia.lawall@...6.fr>
Subject: Re: [PATCH] checkpatch: Add a --strict test for structs with bool
 member definitions

(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.