On Sun, Dec 13, 2020 at 4:38 PM 'Matthias Urlichs' via Clang Built Linux clang-built-linux@googlegroups.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