linux-kernel - Re: [PATCH 0/1] fix rustdoc build detection

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: <20251121101236.5b1f9989@foz.lan>
Date: Fri, 21 Nov 2025 10:12:36 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Carlos Bilbao <carlos.bilbao.osdev@...il.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Carlos Bilbao
 <carlos.bilbao@...nel.org>, Linux Doc Mailing List
 <linux-doc@...r.kernel.org>, Jonathan Corbet <corbet@....net>, Mauro
 Carvalho Chehab <mchehab@...nel.org>, linux-kernel@...r.kernel.org, Miguel
 Ojeda <ojeda@...nel.org>
Subject: Re: [PATCH 0/1] fix rustdoc build detection

Em Tue, 18 Nov 2025 17:23:48 -0600
Carlos Bilbao <carlos.bilbao.osdev@...il.com> escreveu:

> Hey there,
> 
> On 11/17/25 05:22, Miguel Ojeda wrote:
> > On Mon, Nov 17, 2025 at 11:48 AM Mauro Carvalho Chehab
> > <mchehab+huawei@...nel.org> wrote:  
> >> Sure, Sphinx (including kernel-doc) build and rust doca build are
> >> independent. Yet, Makefile "htmldocs" target currently does both.
> >>
> >> It could make sense to have a separate target if one want to build
> >> them both, e.g. something like:  
> > My understanding (Cc'ing Carlos) is that the idea was that `htmldocs`
> > built the Rust docs if possible.  
> 
> 
> Thanks! I'll also take a look at this, although I fear it'll be complicated
> without a way to reproduce what Mauro experienced.

I was able to get the scenario on linux-next. It is a little bit
tricky to reproduce.

1) I did a build with:

	$ make distclean
	$ make SPHINXDIRS=peci htmldocs

   rustdoc was not called.

2) copied a .config that has CONFIG_RUST there:

	$ cp config-rust .config
	$ make SPHINXDIRS=peci htmldocs

   rustdoc was not called.

3) manually called rustdoc:

	$ make rustdoc

   rustdoc was built.

4) now, I re-ran htmldocs:

	$ make SPHINXDIRS=peci htmldocs

   rustdoc was built.

5) I replaced .config with a config without rust:

	$ make allyesconfig
	$ make SPHINXDIRS=peci htmldocs
	...
	Using alabaster theme
	Using Python kernel-doc
	  SYNC    include/config/auto.conf
	  HOSTCC  scripts/basic/fixdep
	  DESCEND objtool
	  INSTALL libsubcmd_headers
	  CC      scripts/mod/empty.o
	  CC      scripts/mod/devicetable-offsets.s
	  MKELF   scripts/mod/elfconfig.h
	  HOSTCC  scripts/mod/modpost.o
	  HOSTCC  scripts/mod/sumversion.o
	  HOSTCC  scripts/mod/symsearch.o
	  HOSTCC  scripts/mod/file2alias.o
	  HOSTLD  scripts/mod/modpost
	  CC      kernel/bounds.s
	  CC      arch/x86/kernel/asm-offsets.s
	  UPD     include/generated/asm-offsets.h
	  CC      kernel/sched/rq-offsets.s
	  CALL    scripts/checksyscalls.sh
	make[4]: *** No rule to make target 'rustdoc'.  Stop.
	make[3]: *** [Makefile:1855: rustdoc] Error 2
	Ignored errors when building rustdoc: Command '['make', 'rustdoc']' returned non-zero exit status 2.. Is RUST enabled?

There are other combinations that produce weird things.

If, instead of step (5), we do:

	$ echo >.config
	$ LANG=C make SPHINXDIRS=peci htmldocs

it will produce, after building htmldocs from Sphinx:

	Using alabaster theme
	Using Python kernel-doc
	  SYNC    include/config/auto.conf
	  HOSTCC  scripts/basic/fixdep
	*
	* Restart config...
	*
	*
	* General setup
	*
	Compile also drivers which will not load (COMPILE_TEST) [N/y/?] (NEW) 

---

My understanding is that the issue is caused because (by purpose)
make htmldocs doesn't sync configuration. It doesn't need, as
building docs doesn't really depend on any .config flag.

However, this check at the Makefile:

	ifneq ($(wildcard $(srctree)/.config),)
	ifeq ($(CONFIG_RUST),y)
        	RUSTDOC=--rustdoc
	endif
	endif

Uses a cached value of "CONFIG_RUST" from the last build, with may
or may not be present anymore.

My patch solves this by not using the cached result, but, instead
checking if CONFIG_RUST is enabled directly at the .config file.

Thanks,
Mauro