All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tamir Duberstein <tamird@kernel.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] printf: mark errptr() noinline
Date: Wed, 8 Apr 2026 13:12:27 +0100	[thread overview]
Message-ID: <20260408131227.0824c330@pumpkin> (raw)
In-Reply-To: <adY8N2sofhMz-6ih@ashevche-desk.local>

On Wed, 8 Apr 2026 14:29:59 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Wed, Apr 08, 2026 at 10:04:25AM +0100, David Laight wrote:
> > On Wed, 8 Apr 2026 09:24:58 +0200
> > Petr Mladek <pmladek@suse.com> wrote:  
> > > On Tue 2026-04-07 16:08:09, David Laight wrote:  
> > > > On Mon, 6 Apr 2026 12:32:32 -0400
> > > > Steven Rostedt <rostedt@goodmis.org> wrote:  
> > > > > On Mon, 6 Apr 2026 11:21:39 -0400
> > > > > Tamir Duberstein <tamird@kernel.org> wrote:  
> 
> ...
> 
> > > > Even having the KASAN/KMSAN code compiled into allmodconfig is a PITA
> > > > when you are trying to check that code compiles to something sensible.    
> > > 
> > > This does not look like a good idea. KASAN/KMSAN are very useful
> > > features. People will want to keep them working. Removing them from
> > > randconfig would just postpone detection of the problem. We would
> > > need to deal with it sooner or later anyway.  
> > 
> > True, but when I build an allmodconfig build to check how the asm looks
> > I really don't want them.  
> 
> Isn't easy to disable that in the command line to `make`?

It is a config option, and I think you need to reset it every time you
rerun 'make allmodconfig' to pick up config changes.

You can enable -Werror with W=e, but not disable it if you want
to set W=1.
I did have a patch that let you use W=1-e which is useful.

	David

> 
> > For the 'bot' builds you also want to know whether they are defined.
> > Changes to how things are built rather than what is built can throw
> > up unexpected warnings that are very hard to pin down.
> > 
> > It is bad enough finding things that affect one obscure architecture
> > with a specific compiler version when the compiler just makes slightly
> > different decisions, without having unusual compilation/config options
> > is the mix to muddy the waters further.  
> 


  reply	other threads:[~2026-04-08 12:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-05 17:31 [PATCH] printf: mark errptr() noinline Tamir Duberstein
2026-04-05 18:17 ` Greg KH
2026-04-06 15:15 ` Steven Rostedt
2026-04-06 15:21   ` Tamir Duberstein
2026-04-06 16:32     ` Steven Rostedt
2026-04-07 11:27       ` Petr Mladek
2026-04-07 13:34         ` Tamir Duberstein
2026-04-08  7:16           ` Petr Mladek
2026-04-08 10:18             ` Tamir Duberstein
2026-04-08 12:28               ` [PATCH v2] printf: Compile the kunit test with DISABLE_BRANCH_PROFILING Petr Mladek
2026-04-08 12:42                 ` Tamir Duberstein
2026-04-14 15:41                   ` [PATCH v3] printf: Compile the kunit test with DISABLE_BRANCH_PROFILING DISABLE_BRANCH_PROFILING Petr Mladek
2026-04-14 16:07                     ` Tamir Duberstein
2026-04-15  9:43                       ` Petr Mladek
2026-04-07 15:08       ` [PATCH] printf: mark errptr() noinline David Laight
2026-04-08  7:24         ` Petr Mladek
2026-04-08  9:04           ` David Laight
2026-04-08 11:29             ` Andy Shevchenko
2026-04-08 12:12               ` David Laight [this message]
2026-04-06 16:40 ` Tamir Duberstein
2026-04-07 10:31 ` David Laight

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=20260408131227.0824c330@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=lkp@intel.com \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=stable@vger.kernel.org \
    --cc=tamird@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.