All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
Cc: "Albert Esteve" <aesteve@redhat.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Brendan Higgins" <brendan.higgins@linux.dev>,
	"David Gow" <david@davidgow.net>,
	"Rae Moar" <raemoar63@gmail.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
	dri-devel@lists.freedesktop.org, workflows@vger.kernel.org,
	linux-doc@vger.kernel.org,
	"Alessandro Carminati" <acarmina@redhat.com>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Kees Cook" <kees@kernel.org>,
	"Linux Kernel Functional Testing" <lkft@linaro.org>,
	"Dan Carpenter" <dan.carpenter@linaro.org>,
	"Maíra Canal" <mcanal@igalia.com>,
	"Simona Vetter" <simona.vetter@ffwll.ch>
Subject: Re: [PATCH v6 0/5] kunit: Add support for suppressing warning backtraces
Date: Tue, 17 Mar 2026 12:30:25 +0100	[thread overview]
Message-ID: <20260317113025.GG2872@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <69f4eb09-efbd-4bd1-81b8-963b78e1a3a3@kernel.org>

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.

So NAK from me on this -- again!

  reply	other threads:[~2026-03-17 11:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-17  9:24 [PATCH v6 0/5] kunit: Add support for suppressing warning backtraces Albert Esteve
2026-03-17  9:24 ` [PATCH v6 1/5] bug/kunit: Core " Albert Esteve
2026-03-17  9:24 ` [PATCH v6 2/5] bug/kunit: Suppressing warning backtraces reduced impact on WARN*() sites Albert Esteve
2026-03-17  9:24 ` [PATCH v6 3/5] Add unit tests to verify that warning backtrace suppression works Albert Esteve
2026-03-17  9:24 ` [PATCH v6 4/5] drm: Suppress intentional warning backtraces in scaling unit tests Albert Esteve
2026-03-17  9:24 ` [PATCH v6 5/5] kunit: Add documentation for warning backtrace suppression API Albert Esteve
2026-03-17 10:03 ` [PATCH v6 0/5] kunit: Add support for suppressing warning backtraces Dan Carpenter
2026-03-17 14:55   ` Guenter Roeck
2026-03-17 11:20 ` Vlastimil Babka (SUSE)
2026-03-17 11:30   ` Peter Zijlstra [this message]
2026-03-17 15:02     ` Guenter Roeck
2026-03-18  9:25     ` Albert Esteve
2026-03-18 11:51       ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260317113025.GG2872@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acarmina@redhat.com \
    --cc=aesteve@redhat.com \
    --cc=airlied@gmail.com \
    --cc=arnd@arndb.de \
    --cc=brendan.higgins@linux.dev \
    --cc=corbet@lwn.net \
    --cc=dan.carpenter@linaro.org \
    --cc=david@davidgow.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kees@kernel.org \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lkft@linaro.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mcanal@igalia.com \
    --cc=mripard@kernel.org \
    --cc=raemoar63@gmail.com \
    --cc=simona.vetter@ffwll.ch \
    --cc=simona@ffwll.ch \
    --cc=skhan@linuxfoundation.org \
    --cc=tzimmermann@suse.de \
    --cc=vbabka@kernel.org \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.