[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zh9i7bpi.fsf@nanos.tec.linutronix.de>
Date: Thu, 04 Jun 2020 23:39:05 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Kees Cook <keescook@...omium.org>
Cc: linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
Alexander Potapenko <glider@...gle.com>,
Joe Perches <joe@...ches.com>,
Andy Whitcroft <apw@...onical.com>, x86@...nel.org,
drbd-dev@...ts.linbit.com, linux-block@...r.kernel.org,
b43-dev@...ts.infradead.org, netdev@...r.kernel.org,
linux-wireless@...r.kernel.org, linux-ide@...r.kernel.org,
linux-clk@...r.kernel.org, linux-spi@...r.kernel.org,
linux-mm@...ck.org, clang-built-linux@...glegroups.com
Subject: Re: [PATCH 01/10] x86/mm/numa: Remove uninitialized_var() usage
Kees Cook <keescook@...omium.org> writes:
>> > -#define NODE_NOT_IN_PAGE_FLAGS
>> > +#define NODE_NOT_IN_PAGE_FLAGS 1
>>
>> but if we ever lose the 1 then the above will silently compile the code
>> within the IS_ENABLED() section out.
>
> That's true, yes. I considered two other ways to do this:
>
> 1) smallest patch, but more #ifdef:
> 2) medium size, weird style:
>
> and 3 is what I sent: biggest, but removes #ifdef
>
> Any preference?
>From a readbility POV I surely prefer #3. i"m just wary. Add a big fat
comment to the define might mitigate that, hmm?
Thanks,
tglx
Powered by blists - more mailing lists