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

Message-ID: <aHgq8nub0DaIMPbp@google.com>
Date: Wed, 16 Jul 2025 22:42:58 +0000
From: Carlos Llamas <cmllamas@...gle.com>
To: Tiffany Yang <ynaffit@...gle.com>
Cc: Kees Cook <kees@...nel.org>, 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 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.

--
Carlos Llamas