linux-kernel - Re: [PATCH v2 6/7] streamline_config.pl: process config options set to "y"

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: <CAK7LNAQ_rzz=iEVGOq-GOWrwBMoVEMtswXKPj3WA2==+0_evdg@mail.gmail.com>
Date: Wed, 6 Nov 2024 08:44:18 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: David Hunter <david.hunter.linux@...il.com>, linux-kbuild@...r.kernel.org, 
	linux-kernel@...r.kernel.org, shuah@...nel.org, 
	javier.carrasco.cruz@...il.com
Subject: Re: [PATCH v2 6/7] streamline_config.pl: process config options set
 to "y"

On Wed, Oct 16, 2024 at 8:19 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Mon, 14 Oct 2024 10:13:36 -0400
> David Hunter <david.hunter.linux@...il.com> wrote:
>
> > An assumption made in this script is that the config options do not need
> > to be processed because they will simply be in the new config file. This
> > assumption is incorrect.
> >
> > Process the config entries set to "y" because those config entries might
> > have dependencies set to "m". If a config entry is set to "m" and is not
> > loaded directly into the machine, the script will currently turn off
> > that config entry; however, if that turned off config entry is a
> > dependency for a "y" option. that means the config entry set to "y"
> > will also be turned off later when the conf executive file is called.
> >
> > Here is a model of the problem (arrows show dependency):
> >
> > Original config file
> > Config_1 (m) <-- Config_2 (y)
> >
> > Config_1 is not loaded in this example, so it is turned off.
> > After scripts/kconfig/streamline_config.pl, but before scripts/kconfig/conf
> > Config_1 (n) <-- Config_2 (y)
> >
> > After  scripts/kconfig/conf
> > Config_1 (n) <-- Config_2 (n)
>
> Hmm, can you show the example of this. My worry here is that there are a
> lot of cases that have:
>
>  Config_1 (m) <-- Config_2 (y)
>
> Where Config_2 is just some binary option to modify the module set by
> Config_1. If we keep Config_1 because there's some 'y' that selects it, we
> are going to keep a lot of unused modules around.

Basically, there is no good way to distinguish
in-module option (just CONFIG_BCACHEFS_SIX_OPTIMISTIC_SPIN=y,
which is a property for CONFIG_BCACHEFS=m) from real dependency.




> >
> > It should also be noted that any module in the dependency chain will
> > also be turned off, even if that module is loaded directly onto the
> > computer. Here is an example:
> >
> > Original config file
> > Config_1 (m) <-- Config_2 (y) <-- Config_3 (m)
>
> If Config_3 is used, then it should add Config_2 as a dependency. I guess
> that's what this patch does.

Agree, but I am not sure how to pick up only this case.


-- 
Best Regards
Masahiro Yamada