From: Vincenzo Frascino <vincenzo.frascino@arm.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kconfig: Sanitize make randconfig generated .config
Date: Fri, 7 Feb 2020 10:40:14 +0000 [thread overview]
Message-ID: <809349aa-2150-da9f-1efb-a257fb60aaf5@arm.com> (raw)
In-Reply-To: <CAK7LNATxbGWGW19N9H-HAiSY0AL0iFs8D_H0DEKmEfTGTT88iA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2347 bytes --]
On 01/02/2020 03:12, Masahiro Yamada wrote:
> Hi.
>
>
> On Wed, Jan 22, 2020 at 7:03 PM Vincenzo Frascino
> <vincenzo.frascino@arm.com> wrote:
>>
>> "make randconfig" calculates the probability of a tristate option (yes,
>> mod, no) based on srand()/rand() and can be fed with a seed.
>> At the last step of randconfig some option are chosen randomly and their
>> tristate set based on similar mechanism.
>> After this passage the resulting .config is not sanitized, hence it
>> might result in an inconsistent set of options being selected.
>>
>> This was noticed on arm64 using KCONFIG_SEED=0x40C5E904. During
>> randomize_choice_values() CONFIG_BIG_ENDIAN is enabled. Since CONFIG_EFI
>> was enabled at a previous step, and depends on !CONFIG_BIG_ENDIAN the
>> resulting .config is inconsistent.
>>
>> Fix the issue making sure that randconfig sanitizes the generated
>> .config as a last step.
>>
>> Cc: Masahiro Yamada <masahiroy@kernel.org>
>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>> ---
>> scripts/kconfig/conf.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
>> index 1f89bf1558ce..c0fcaa4e9762 100644
>> --- a/scripts/kconfig/conf.c
>> +++ b/scripts/kconfig/conf.c
>> @@ -654,6 +654,11 @@ int main(int ac, char **av)
>> case randconfig:
>> /* Really nothing to do in this loop */
>> while (conf_set_all_new_symbols(def_random)) ;
>> + /*
>> + * .config at this point might contain
>> + * incompatible options. Sanitize it.
>> + */
>> + sym_clear_all_valid();
>
> Thanks for the report, but clearing
> all the valid flags is a big hammer.
> I do not think it is a proper fix.
>
>
Ok, it is fine by me to find a better solution in this case. Not being on the
critical path of execution it did not look like to me very heavy but my
experience with the tool code is limited :)
> I checked the code, and I noticed the root cause of
> this bug.
>
> I will send a different patch later.
>
>
>
>
>> break;
>> case defconfig:
>> conf_set_all_new_symbols(def_default);
>> --
>> 2.25.0
>>
>
>
--
Regards,
Vincenzo
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 14291 bytes --]
prev parent reply other threads:[~2020-02-07 10:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-22 10:03 Vincenzo Frascino
2020-02-01 3:12 ` Masahiro Yamada
2020-02-01 5:15 ` Masahiro Yamada
2020-02-07 10:40 ` Vincenzo Frascino [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=809349aa-2150-da9f-1efb-a257fb60aaf5@arm.com \
--to=vincenzo.frascino@arm.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®