linux-kernel - Re: [PATCH v3 4/6] binder: Scaffolding for binder

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] [day] [month] [year] [list]

Message-ID: <202507162321.33950FA92A@keescook>
Date: Wed, 16 Jul 2025 23:22:53 -0700
From: Kees Cook <kees@...nel.org>
To: Carlos Llamas <cmllamas@...gle.com>
Cc: Tiffany Yang <ynaffit@...gle.com>, linux-kernel@...r.kernel.org,
	kernel-team@...roid.com,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Todd Kjos <tkjos@...roid.com>, Martijn Coenen <maco@...roid.com>,
	Joel Fernandes <joelagnelf@...dia.com>,
	Christian Brauner <brauner@...nel.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Brendan Higgins <brendan.higgins@...ux.dev>,
	David Gow <davidgow@...gle.com>, Rae Moar <rmoar@...gle.com>,
	linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com
Subject: Re: [PATCH v3 4/6] binder: Scaffolding for binder_alloc KUnit tests

On Wed, Jul 16, 2025 at 10:42:58PM +0000, Carlos Llamas wrote:
> On Wed, Jul 16, 2025 at 03:28:49PM -0700, Tiffany Yang wrote:
> > Kees Cook <kees@...nel.org> writes:
> > 
> > > > ...
> > 
> > > I'm used to the "#ifdef CONFIG_..." idiom, but looking at the tree, I
> > > see that "#if IS_ENANLED(CONFIG...)" is relatively common too. I don't
> > > think there is a function difference, so I leave the style choice up to
> > > you! ;)
> > 
> > 
> > IIRC, I had tried using the #ifdef to inject test-specific code in some
> > places, but that created issues when we were loading KUnit as a module
> > because it causes the built-in code to be built as though the
> > "CONFIG_..." is undefined. Consequently, I started using IS_ENABLED by
> > default, but I'm not sure if it's strictly necessary for exposing
> > functions with a header file since I'd assume "CONFIG_..." will be
> > defined when we're building the module?
> 
> Right, IS_ENABLED() is the "short-hand" for ...
> 	#if defined(CONFIG_x) || defined(CONFIG_x_MODULE)
> ... which is what we need here.

Ah-ha! Okay, thanks for the explanation. I don't do much module work,
it seems. ;)

-- 
Kees Cook