linux-kernel - Re: [PATCH] kbuild: install-extmod-build: do not exclude scripts/dtc/libfdt/

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: <CAL_JsqJdS77S8VD-smpBi_mSZ6s3C66mvh5OCzQNhWMTyvjp-w@mail.gmail.com>
Date: Wed, 4 Feb 2026 07:31:57 -0600
From: Rob Herring <robh@...nel.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Icenowy Zheng <uwu@...nowy.me>, Nicolas Schier <nsc@...nel.org>, 
	Masahiro Yamada <masahiroy@...nel.org>, Abel Vesa <abelvesa@...nel.org>, 
	Mingcong Bai <jeffbai@...c.io>, WangYuli <wangyuli@...ontech.com>, 
	Inochi Amaoto <inochiama@...il.com>, James Le Cuirot <chewi@...too.org>, linux-kbuild@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Rong Zhang <i@...g.moe>, 
	Saravana Kannan <saravanak@...nel.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH] kbuild: install-extmod-build: do not exclude scripts/dtc/libfdt/

On Wed, Feb 4, 2026 at 2:45 AM Nathan Chancellor <nathan@...nel.org> wrote:
>
> On Wed, Feb 04, 2026 at 11:27:24AM +0800, Icenowy Zheng wrote:
> > 在 2026-02-04星期三的 11:26 +0800，Icenowy Zheng写道：
> > > 在 2026-02-03星期二的 19:16 -0700，Nathan Chancellor写道：
> > > > + Rob, Saravana, and devicetree@ since this concerns files they
> > > > own.
> > > >
> > > > On Sun, Feb 01, 2026 at 09:02:59PM +0800, Icenowy Zheng wrote:
> > > > > There exists a header file in include/linux/ called libfdt.h that
> > > > > is
> > > > > just a wrapper for libfdt header file in scripts/dtc/libfdt/.
> > > > > This
> > > > > makes
> > > > > the headers inside libfdt copy at scripts/dtc/libfdt/ part of the
> > > > > kernel
> > > > > headers for building external modules.
> > > > >
> > > > > Do not exclude them, otherwise modules that include
> > > > > <linux/libfdt.h>
> > > > > will fail to build externally.
> > > > >
> > > > > Fixes: aaed5c7739be ("kbuild: slim down package for building
> > > > > external modules")
> > > > > Signed-off-by: Icenowy Zheng <zhengxingda@...as.ac.cn>
> > > >
> > > > This does indeed bring back scripts/dtc/libfdt back into the
> > > > headers
> > > > package that I examined. However, how does including libfdt.h in an
> > > > external module actually work, even with this change? libfdt
> > > > appears
> > > > to
> > > > be built into vmlinux IIUC and I do not see any EXPORT_SYMBOLs in
> > > > the
> > > > list, so how can you actually use any of the functions from libfdt
> > > > within the module? Would you just build and link the pieces that
> > > > your
> > > > module needs using the other source files?
> > >
> > > To be honest what I met is quite weird -- my module [1] does not use
> > > libfdt at all. However, as a MIPS platform-specific module, it
> > > includes
> > > arch/mips/include/asm/bootinfo.h, which pulls in libfdt.h.
> > >
> > > Or maybe I should prevent libfdt.h inclusion from other kernel
> > > headers?
> > > It looks like only two headers in MIPS architecture-specific code
> > > includes libfdt.h, asm/bootinfo.h and asm/machine.h .
>
> Ah, thanks for that information. Moving the libfdt.h bits out of
> bootinfo.h does not seem like it would be too difficult but I am less
> sure about asm/machine.h. Alternatively, maybe this could be avoided by
> separating out what you would need from bootinfo.h into its own header
> but I did not look too hard.

There shouldn't be that many locations using libfdt functions. Add the
header where it is used. IWYU

> As for a solution within install-extmod-build, maybe the libfdt headers
> could be included so that inadvertent inclusions of libfdt.h do not
> break the build but the link fails if the module actually tries to use
> any libfdt functions?

You do this and then we get to keep the work-around forever as no one
will care. MIPS is a mess that needs to be cleaned up.

Rob