Re: [PATCH] kbuild: don't delete in-flight filechk temporaries in asm-headers

[Thomas Weißschuh]

On Wed, Sep 02, 2026 at 09:13:47AM -0700, Vlad Poenaru wrote:
> Commit 2d69b891e646 ("kbuild: Support generated asm-headers in
> subdirectories") switched the stale-wrapper sweep in
> scripts/Makefile.asm-headers from $(wildcard $(obj)/*.h) to a find(1)
> invocation, so that generated headers in subdirectories are considered.
> 
> The two do not match the same set of files. Make's $(wildcard) uses glob
> semantics, where a leading '.' has to be matched explicitly, whereas
> find's -name uses fnmatch() without FNM_PERIOD, so '*.h' matches
> dotfiles as well. filechk writes its output to $(dir $@).tmp_$(notdir $@)
> before renaming it into place, so such a scratch file, if it happens to
> exist in $(obj) when the sub-make is parsed, is now picked up in
> old-headers. It appears in neither generic-y, generated-y nor syscall-y,
> is therefore classified as unwanted, and cmd_remove deletes it.
> 
> On x86 this races with archprepare, which lists both asm-generic and
> arch/x86/include/generated/asm/cpufeaturemasks.h as prerequisites. Under
> -j they run concurrently against the same directory, and the build fails
> intermittently:
> 
>   mv: cannot stat 'arch/x86/include/generated/asm/.tmp_cpufeaturemasks.h': No such file or directory
>   make[1]: *** [arch/x86/Makefile:269: arch/x86/include/generated/asm/cpufeaturemasks.h] Error 1
> 
> The same commit also converted the generic wrapper rule to filechk, so
> those wrappers now create .tmp_*.h in $(obj) too and can race among
> themselves.
> 
> Restore the previous behaviour by excluding dotfiles from the sweep.
> Subdirectories, which is what the find(1) conversion was for, keep being
> descended into. While at it, quote the -name argument: it is currently
> expanded by the shell against the build directory before find sees it.
> 
> Fixes: 2d69b891e646 ("kbuild: Support generated asm-headers in subdirectories")
> Signed-off-by: Vlad Poenaru <vlad.wing@xxxxxxxxx>

Thanks, and sorry for the breakage!

Reviewed-by: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxxxx>

(...)