From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-f66.google.com (mail-pj1-f66.google.com [209.85.216.66]) by mail19.linbit.com (LINBIT Mail Daemon) with ESMTP id BFA974203B3 for ; Fri, 5 Jun 2020 00:39:31 +0200 (CEST) Received: by mail-pj1-f66.google.com with SMTP id ga6so1735712pjb.1 for ; Thu, 04 Jun 2020 15:39:31 -0700 (PDT) Date: Thu, 4 Jun 2020 15:39:28 -0700 From: Kees Cook To: Thomas Gleixner Message-ID: <202006041539.B8C0C768@keescook> References: <20200603233203.1695403-2-keescook@chromium.org> <874krr8dps.fsf@nanos.tec.linutronix.de> <202006040728.8797FAA4@keescook> <87zh9i7bpi.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zh9i7bpi.fsf@nanos.tec.linutronix.de> Cc: Andy Whitcroft , clang-built-linux@googlegroups.com, linux-ide@vger.kernel.org, netdev@vger.kernel.org, x86@kernel.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, linux-block@vger.kernel.org, Miguel Ojeda , linux-mm@kvack.org, Alexander Potapenko , b43-dev@lists.infradead.org, Joe Perches , Linus Torvalds , linux-clk@vger.kernel.org, drbd-dev@lists.linbit.com Subject: Re: [Drbd-dev] [PATCH 01/10] x86/mm/numa: Remove uninitialized_var() usage List-Id: "*Coordination* of development, patches, contributions -- *Questions* \(even to developers\) go to drbd-user, please." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Jun 04, 2020 at 11:39:05PM +0200, Thomas Gleixner wrote: > Kees Cook 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