Re: [PATCH v6 0/5] kunit: Add support for suppressing warning backtraces

[Guenter Roeck <linux@roeck-us.net>]

On 3/17/26 04:30, Peter Zijlstra wrote:
> On Tue, Mar 17, 2026 at 12:20:26PM +0100, Vlastimil Babka (SUSE) wrote:
>>> For this iteration, the `__report_bug()` centralized approach was
>>> revisited after the discussion in the previous version [1].
>>
>> Discussion with PeterZ, who is not CC'd here? (did it now for my reply).
>>
>>> However, again this approach did not work because:
>>> - Some warning output is generated directly in the macros before calling
>>>    the centralized functions (e.g., `__warn_printk()` in `__WARN_printf()`)
>>> - Functions in the warning path like `warn_slowpath_fmt()` are marked
>>>    `__always_inline`, making it difficult to intercept early enough
>>> - So, by the time `__report_bug()` is called, output has already been written
>>>    to the console, making suppression ineffective
>>>
>>> Current Proposal: Check Directly in the `WARN()` Macros.
>>> This avoids the need for function symbol resolution or ELF section
>>> modification.
>>> Suppression is implemented directly in the `WARN*()` macros.
>>
>> So does that bloat every warn/bug site (as Peter objected to) or not?
>> And is it compatible with x86? I see you modify include/asm-generic/bug.h
>> but x86 has its own version of e.g. __WARN_printf ?
> 
> Yeah, they done it all wrong again :-(
> 
> This should be pushed inside __report_bug() through __WARN_printf with a
> new BUGFLAG thing.
> 

That would require another set of WARN macros, and after (or if) accepted
negotiations with each of the owners of the WARNing code to use the new
macros. Trying to do this would just trigger another set of objections.

Given that, but for other reasons,

> So NAK from me on this -- again!

I agree.

Guenter