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: <f630f4b595027fbd60d440eb90c3e332c2b52def.camel@icenowy.me>
Date: Thu, 05 Feb 2026 16:22:05 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Nathan Chancellor <nathan@...nel.org>
Cc: 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>, Rob Herring
 <robh@...nel.org>, Saravana Kannan <saravanak@...nel.org>, 
 devicetree@...r.kernel.org
Subject: Re: [PATCH] kbuild: install-extmod-build: do not exclude
 scripts/dtc/libfdt/

在 2026-02-04星期三的 01:45 -0700,Nathan Chancellor写道:
> 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.

A bad joke -- the driver seems to require no bootinfo.h now. It's a
stale inclusion (because it's taken from some downstream tree and
rewritten to use mainline i8042 lock). Sorry for this...

Although I do think the libfdt.h inclusion should be removed from MIPS
headers.

For testing this any stub module can work with `#include
<asm/bootinfo.h>` (or machine.h) injected...

> 
> 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?

I don't think it proper either.

By the way, should include/linux/libfdt.h be removed from extmod build
installations? As it's not going to work...

> 
> > Ah, forgot to place the [1] reference link, although I doubt
> > whether
> > it's really related to the context:
> > 
> > [1] https://github.com/Icenowy/mips-loong-3nod-laptop-driver
> 
> This was helpful for testing the following diff, so thanks for
> providing
> it still.
> 
> Cheers,
> Nathan


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ