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
| ||
|
Date: Sun, 13 Dec 2020 17:32:38 +0100 From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com> To: Matthias Urlichs <matthias@...ichs.de> Cc: Greg KH <gregkh@...uxfoundation.org>, 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 4:38 PM 'Matthias Urlichs' via Clang Built Linux <clang-built-linux@...glegroups.com> 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 `CONFIG_ENABLE_MUST_CHECK` for *years*. > 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 concern. 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. Cheers, Miguel
Powered by blists - more mailing lists