netdev - Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST

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 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]

Date:   Sun, 13 Dec 2020 16:16:45 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Masahiro Yamada <masahiroy@...nel.org>,
        "Jason A . Donenfeld" <Jason@...c4.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Shuah Khan <shuah@...nel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        wireguard@...ts.zx2c4.com
Subject: Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK

On Sun, Dec 13, 2020 at 03:58:20PM +0100, Miguel Ojeda wrote:
> > The key here is "if nobody complains". I would argue that it is _your_
> > responsibility to do those builds, and not the reponsibility of others
> > to do it for you.
> 
> Testing allmodconfig for a popular architecture, agreed, it is due
> diligence to avoid messing -next that day.
> 
> Testing a matrix of configs * arches * gcc/clang * compiler versions?
> No, sorry, that is what CI/-next/-rcs are for and that is where the
> "if nobody complains" comes from.
> 
> If you think building a set of code for a given arch/config/etc. is
> particularly important, then it is _your_ responsibility to build it
> once in a while in -next (as you have done). If it is not that
> important, somebody will speak up in one -rc. If not, is anyone
> actually building that code at all?
> 
> Otherwise, changing core/shared code would be impossible. Please don't
> blame the author for making a sensible change that will improve code
> quality for everyone.
> 
> > But, sure, your call. Please feel free to ignore my report.
> 
> I'm not ignoring the report, quite the opposite. I am trying to
> understand why you think reverting is needed for something that has
> been more than a week in -next without any major breakage and still
> has a long road to v5.11.

Because if you get a report of something breaking for your change, you
need to work to resolve it, not argue about it.  Otherwise it needs to
be dropped/reverted.

Please fix.

thanks,

greg k-h