From: Heiko Carstens <hca@linux.ibm.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
Kees Cook <keescook@chromium.org>,
linux-hardening@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Arnd Bergmann <arnd@kernel.org>
Subject: Re: [PATCH] gcc-plugins: Disable GCC_PLUGIN_CYC_COMPLEXITY for s390
Date: Tue, 23 Feb 2021 19:03:47 +0100 [thread overview]
Message-ID: <YDVDg/EZWjCZQn2v@osiris> (raw)
In-Reply-To: <20210223174140.GA159796@roeck-us.net>
On Tue, Feb 23, 2021 at 09:41:40AM -0800, Guenter Roeck wrote:
> > I tried to explain why we don't want to set COMPILE_TEST for s390
> > anymore. It overrides architecture dependencies in Kconfig, and lots
> > of drivers do not set dependencies for HAS_IOMEM, HAS_DMA, and friends
> > correctly.
> > This generates constantly fallout which is irrelevant for s390 and
> > also for other architectures. It generates just work with close to
> > zero benefit. For drivers which matter for s390 we still see those
> > errors.
> >
> > > On the other side, if that flag would be set explicitly by
> > > all{yes,mod}config, it would really beg for being misused. We
> > > might then as well add a new flag that is explicitly associated
> > > with all{yes,mod}config, but not with randconfig.
> >
> > I think that makes most sense, probably also have a flag that is set
> > for randconfig.
>
> Not sure what value such an option would have, and how it would be used.
> I would argue that randconfig should not set COMPILE_TEST to start with,
> since its purpose should be to test random valid configurations and not
> to compile test arbitrary (and in that case random) code. But that is
> a different question, and just my personal opinion.
>
> Overall, the question is what kind of additional option you would find
> useful for s390. You make it clear that you don't want COMPILE_TEST.
> At the same time, you still want all{mod,yes}config, but presumably
> excluding options currently restricted by !COMPILE_TEST (such as
> DEBUG_INFO, BPF_PRELOAD, UBSAN_TRAP, GCC_PLUGIN_CYC_COMPLEXITY,
> and a few others). SUPPRESS_NOISY_TESTS would not cover that, but
> neither would RANDCONFIG (or whatever it would be called).
Well, if we would have e.g. RANDCONFIG, then we could probably revert
334ef6ed06fa ("init/Kconfig: make COMPILE_TEST depend on !S390") and
instead let COMPILE_TEST depend on !RANDCONFIG.
I think this _could_ solve all common problems we currently see.
And it would also do what you suggested.
next prev parent reply other threads:[~2021-02-23 18:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-21 22:56 [PATCH] gcc-plugins: Disable GCC_PLUGIN_CYC_COMPLEXITY for s390 Guenter Roeck
2021-02-22 12:05 ` Heiko Carstens
2021-02-22 15:18 ` Guenter Roeck
2021-02-22 15:45 ` Masahiro Yamada
2021-02-22 16:03 ` Guenter Roeck
2021-02-23 11:54 ` Heiko Carstens
2021-02-23 17:41 ` Guenter Roeck
2021-02-23 18:03 ` Heiko Carstens [this message]
2021-02-23 18:17 ` Kees Cook
2021-02-24 1:46 ` Guenter Roeck
2021-02-24 14:19 ` Masahiro Yamada
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=YDVDg/EZWjCZQn2v@osiris \
--to=hca@linux.ibm.com \
--cc=arnd@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.