linux-kernel - Re: [RFC PATCH 2/3] kbuild: Make sure to generate config file

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: <20260122051558.GB3770486@ax162>
Date: Wed, 21 Jan 2026 22:15:58 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Tiezhu Yang <yangtiezhu@...ngson.cn>
Cc: Nicolas Schier <nsc@...nel.org>, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 2/3] kbuild: Make sure to generate config file

On Thu, Jan 22, 2026 at 09:14:07AM +0800, Tiezhu Yang wrote:
> Currently, CONFIG_IKCONFIG_PROC is set by default on LoongArch,
> the above error still exists, it checks /boot/config-* first,
> here is the related code:
> 
> tools/testing/selftests/bpf/unpriv_helpers.c:
> static gzFile open_config(void)
> {
>         struct utsname uts;
>         char buf[PATH_MAX];
>         gzFile config;
> 
>         if (uname(&uts)) {
>                 perror("uname");
>                 goto config_gz;
>         }
> 
>         snprintf(buf, sizeof(buf), "/boot/config-%s", uts.release);
>         config = gzopen(buf, "rb");
>         if (config)
>                 return config;
>         fprintf(stderr, "gzopen %s: %s\n", buf, strerror(errno));
> 
> config_gz:
>         config = gzopen("/proc/config.gz", "rb");
>         if (!config)
>                 perror("gzopen /proc/config.gz");
>         return config;
> }

Ah but it still falls back to /proc/config.gz though, right?

> Yes, this works well for LoongArch. If there is no need to do this for
> all archs, I will only touch arch/loongarch files.

Until there is a wider insistance on including these as part of the
install target, I think it would be best to keep this in arch/loongarch,
as that is the only architecture that would notice in this case.

> By the way, I do not know why it can not generate System.map by the
> installkernel in practice, could you please check it?

Is installkernel a part of the kernel source? I am not sure where to
begin to investigate that. Could be an inaccurate comment as well if
installkernel's implementation has been updated.

Cheers,
Nathan