LKML Archive on
help / color / mirror / Atom feed
From: Peter Hurley <>
To: Louis Langholtz <>,
Subject: Re: [PATCH 0/4] int to bool conversion
Date: Fri, 30 Jan 2015 13:21:21 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Louis,

On 01/30/2015 12:32 PM, Louis Langholtz wrote:
> While it may not be productive to perturb seemingly working
> code (as Rafael argues), it may also not be productive to
> have decreased code readability (as Quentin suggests).
> Personally I prefer readability enhancements over worrying
> about possibly breaking working code. I don't want to start
> a flame war so I won't go into arguing this as a better
> position. I'd just like to thank Quentin for his efforts to
> identify boolean uses of variables. It's something I'm
> interested in as well and have been working on in a branch
> of my own git repository.
> Quentin if you want to work on this together at all, that'd
> be great. Please contact me directly as I'm not subscribed to
> the LKML. As for the original semantic patch code, it's
> unlikely that it would be safe to not exclude variables that
> are passed by address (and seemingly the ampersand operator
> applied on x - as in '&x' - should be a part of the exclusion
> set).

Just a quick note about bools vs. ints in kernel code:
one of the required arch guarantees is that an int is a
unique memory location, whereas a bool does not provide that
guarantee. Much kernel code requires unique memory locations.

For instance, in the example below, do_something() may not execute.

static bool x;
static bool y;

CPU 0                     | CPU 1
                          | y = 1;
x = 1;                    |
                          | if (y)
                          |    do_something();

The reason is that the 'x = 1' statement may be a RMW operation
if the compiler has merged x and y into the same memory
location. So that what really happens is

u8 xy;

CPU 0                     | CPU 1
                          | load [xy]=> R
			  | R |= Y_BIT
load [xy] => R            |
R |= X_BIT                |
                          | store R => [xy]
store R => [xy]           |
                          | if ([xy] & Y_BIT)
                          |    do_something();

I looked over the patches when they were first posted and
none involve concurrent access, so I didn't mention it.
But a general campaign of int=>bool will need to be aware
of this.

Peter Hurley

PS - In fact, even chars or shorts can be RMW on the entire
machine word.

  reply	other threads:[~2015-01-30 18:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-30 17:32 Louis Langholtz
2015-01-30 18:21 ` Peter Hurley [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-01-22  8:49 Quentin Lambert
2015-01-22 16:18 ` Rafael J. Wysocki
2015-01-26  8:30   ` Quentin Lambert
2015-01-26 13:32     ` Rafael J. Wysocki
2015-02-18 19:09       ` Moore, Robert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: [PATCH 0/4] int to bool conversion' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).