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 17:32:38 +0100
From:   Miguel Ojeda <>
To:     Matthias Urlichs <>
Cc:     Greg KH <>,
        Guenter Roeck <>,
        Masahiro Yamada <>,
        "Jason A . Donenfeld" <>,
        Nathan Chancellor <>,
        Nick Desaulniers <>,
        Shuah Khan <>,
        clang-built-linux <>,
        linux-kernel <>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        Network Development <>,
Subject: Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK

On Sun, Dec 13, 2020 at 4:38 PM 'Matthias Urlichs' via Clang Built
Linux <> wrote:
> If your change to a function breaks its callers, it's your job to fix

No function has changed. This patch enables a warning (that for some
reason is an error in the case of Guenter).

Even if this was a hard error, the same applies: the function hasn't
changed. It just means callers never tested with

> the callers proactively instead of waiting for "as they come" bug
> reports. (Assuming, of course, that you know about the breakage. Which
> you do when you tell us that the bad pattern can simply be grepped for.)

No, *we don't know about the breakage*. The grep was for the
particular function Guenter reported, and done to validate his

If you want to manually inspect every caller of every `__must_check`
function, or to write a cocci patch or a clang-tidy check or similar
(that would be obsolete as soon as `__must_check` is enabled), you are
welcome to do so. But a much better usage of our time would be letting
machines do their job.

> If nothing else, that's far more efficient than [number_of_callers]
> separate patches by other people who each need to find the offending
> change, figure out what to change and/or who to report the problem to,
> and so on until the fix lands in the kernel.

This change is not in Linus' tree, it is on -next.

> Moreover, this wouldn't leave the kernel sources in a non-bisect-able
> state during that time.

Again, the change is in -next. That is the point: to do integration
testing and let the bots run against it.


Powered by blists - more mailing lists