[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202006041539.B8C0C768@keescook>
Date: Thu, 4 Jun 2020 15:39:28 -0700
From: Kees Cook <keescook@...omium.org>
To: Thomas Gleixner <tglx@...utronix.de>
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
On Thu, Jun 04, 2020 at 11:39:05PM +0200, Thomas Gleixner wrote:
> 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?
Sure! I'll add it.
--
Kees Cook
Powered by blists - more mailing lists