All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: 20190819234111.9019-8-keescook@chromium.org
Cc: Kees Cook <keescook@chromium.org>,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	Peter Zijlstra <peterz@infradead.org>,
	Drew Davenport <ddavenport@chromium.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"Steven Rostedt (VMware)" <rostedt@goodmis.org>,
	Feng Tang <feng.tang@intel.com>, Petr Mladek <pmladek@suse.com>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Borislav Petkov <bp@suse.de>, YueHaibing <yuehaibing@huawei.com>,
	linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 7/7] bug: Move WARN_ON() "cut here" into exception handler
Date: Thu, 22 Aug 2019 15:56:11 -0700	[thread overview]
Message-ID: <20190822155611.a1a6e26db99ba0876ba9c8bd@linux-foundation.org> (raw)
In-Reply-To: <201908200943.601DD59DCE@keescook>

On Tue, 20 Aug 2019 09:47:55 -0700 Kees Cook <keescook@chromium.org> wrote:

> Reply-To: 20190819234111.9019-8-keescook@chromium.org

Really?

> Subject: [PATCH v2 7/7] bug: Move WARN_ON() "cut here" into exception handler

It's strange to receive a standalone [7/7] patch.

> Date:   Tue, 20 Aug 2019 09:47:55 -0700
> Sender: linux-kernel-owner@vger.kernel.org
> 
> The original clean up of "cut here" missed the WARN_ON() case (that
> does not have a printk message), which was fixed recently by adding
> an explicit printk of "cut here". This had the downside of adding a
> printk() to every WARN_ON() caller, which reduces the utility of using
> an instruction exception to streamline the resulting code. By making
> this a new BUGFLAG, all of these can be removed and "cut here" can be
> handled by the exception handler.
> 
> This was very pronounced on PowerPC, but the effect can be seen on
> x86 as well. The resulting text size of a defconfig build shows some
> small savings from this patch:
> 
>    text    data     bss     dec     hex filename
> 19691167        5134320 1646664 26472151        193eed7 vmlinux.before
> 19676362        5134260 1663048 26473670        193f4c6 vmlinux.after
> 
> This change also opens the door for creating something like BUG_MSG(),
> where a custom printk() before issuing BUG(), without confusing the "cut
> here" line.

I can't get this to apply to anything, so I guess that [1/7]-[6/7]
mattered ;)

> Reported-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Fixes: Fixes: 6b15f678fb7d ("include/asm-generic/bug.h: fix "cut here" for WARN_ON for __WARN_TAINT architectures")

I'm seeing double.

> Signed-off-by: Kees Cook <keescook@chromium.org>


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: 20190819234111.9019-8-keescook@chromium.org
Cc: Christophe Leroy <christophe.leroy@c-s.fr>,
	Peter Zijlstra <peterz@infradead.org>,
	Drew Davenport <ddavenport@chromium.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"Steven Rostedt (VMware)" <rostedt@goodmis.org>,
	Feng Tang <feng.tang@intel.com>, Petr Mladek <pmladek@suse.com>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Borislav Petkov <bp@suse.de>, YueHaibing <yuehaibing@huawei.com>,
	linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 7/7] bug: Move WARN_ON() "cut here" into exception handler
Date: Thu, 22 Aug 2019 15:56:11 -0700	[thread overview]
Message-ID: <20190822155611.a1a6e26db99ba0876ba9c8bd@linux-foundation.org> (raw)
Message-ID: <20190822225611.0Kb_8U6Flk_5ufasRfJzfMWExyygP8nr83WXRCu1p0o@z> (raw)
In-Reply-To: <201908200943.601DD59DCE@keescook>

On Tue, 20 Aug 2019 09:47:55 -0700 Kees Cook <keescook@chromium.org> wrote:

> Reply-To: 20190819234111.9019-8-keescook@chromium.org

Really?

> Subject: [PATCH v2 7/7] bug: Move WARN_ON() "cut here" into exception handler

It's strange to receive a standalone [7/7] patch.

> Date:   Tue, 20 Aug 2019 09:47:55 -0700
> Sender: linux-kernel-owner@vger.kernel.org
> 
> The original clean up of "cut here" missed the WARN_ON() case (that
> does not have a printk message), which was fixed recently by adding
> an explicit printk of "cut here". This had the downside of adding a
> printk() to every WARN_ON() caller, which reduces the utility of using
> an instruction exception to streamline the resulting code. By making
> this a new BUGFLAG, all of these can be removed and "cut here" can be
> handled by the exception handler.
> 
> This was very pronounced on PowerPC, but the effect can be seen on
> x86 as well. The resulting text size of a defconfig build shows some
> small savings from this patch:
> 
>    text    data     bss     dec     hex filename
> 19691167        5134320 1646664 26472151        193eed7 vmlinux.before
> 19676362        5134260 1663048 26473670        193f4c6 vmlinux.after
> 
> This change also opens the door for creating something like BUG_MSG(),
> where a custom printk() before issuing BUG(), without confusing the "cut
> here" line.

I can't get this to apply to anything, so I guess that [1/7]-[6/7]
mattered ;)

> Reported-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Fixes: Fixes: 6b15f678fb7d ("include/asm-generic/bug.h: fix "cut here" for WARN_ON for __WARN_TAINT architectures")

I'm seeing double.

> Signed-off-by: Kees Cook <keescook@chromium.org>

  reply	other threads:[~2019-08-22 22:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20 16:47 [PATCH v2 7/7] bug: Move WARN_ON() "cut here" into exception handler Kees Cook
2019-08-22 22:56 ` Andrew Morton [this message]
2019-08-22 22:56   ` Andrew Morton
2019-08-23 14:26   ` Christophe Leroy
2019-08-23 14:26     ` Christophe Leroy
2019-08-24 19:08     ` Kees Cook
2019-08-29  4:55       ` Christophe Leroy
2019-08-29 16:12         ` Kees Cook
2019-08-23 14:56 ` Christophe Leroy
2019-09-09 16:05 ` Sergey Senozhatsky
2019-09-10  8:59   ` Kees Cook
2019-09-10  9:16     ` Sergey Senozhatsky

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=20190822155611.a1a6e26db99ba0876ba9c8bd@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=20190819234111.9019-8-keescook@chromium.org \
    --cc=arnd@arndb.de \
    --cc=bp@suse.de \
    --cc=christophe.leroy@c-s.fr \
    --cc=ddavenport@chromium.org \
    --cc=feng.tang@intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab+samsung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=yuehaibing@huawei.com \
    /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.