From: Marco Elver <elver@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
"the arch/x86 maintainers" <x86@kernel.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
kasan-dev <kasan-dev@googlegroups.com>,
LKML <linux-kernel@vger.kernel.org>,
Will Deacon <will@kernel.org>, Dmitry Vyukov <dvyukov@google.com>,
Alexander Potapenko <glider@google.com>,
Andrey Konovalov <andreyknvl@google.com>
Subject: Re: [PATCH 0/9] x86/entry fixes
Date: Wed, 3 Jun 2020 21:10:02 +0200 [thread overview]
Message-ID: <CANpmjNPJ_vTyTYyrXxP2ei0caLo10niDo8PapdJj2s4-w_R3TA@mail.gmail.com> (raw)
In-Reply-To: <20200603181638.GD2627@hirez.programming.kicks-ass.net>
On Wed, 3 Jun 2020 at 20:16, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, Jun 03, 2020 at 06:07:22PM +0200, Peter Zijlstra wrote:
> > On Wed, Jun 03, 2020 at 04:47:54PM +0200, Marco Elver wrote:
>
> > > With that in mind, you could whitelist "__ubsan_handle"-prefixed
> > > functions in objtool. Given the __always_inline+noinstr+__ubsan_handle
> > > case is quite rare, it might be reasonable.
> >
> > Yes, I think so. Let me go have dinner and then I'll try and do a patch
> > to that effect.
>
> Here's a slightly more radical patch, it unconditionally allows UBSAN.
>
> I've not actually boot tested this.. yet.
>
> ---
> Subject: x86/entry, ubsan, objtool: Whitelist __ubsan_handle_*()
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Wed Jun 3 20:09:06 CEST 2020
>
> The UBSAN instrumentation only inserts external CALLs when things go
> 'BAD', much like WARN(). So treat them similar to WARN()s for noinstr,
> that is: allow them, at the risk of taking the machine down, to get
> their message out.
>
> Suggested-by: Marco Elver <elver@google.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
This is much cleaner, as it gets us UBSAN coverage back. Seems to work
fine for me (only lightly tested), so
Acked-by: Marco Elver <elver@google.com>
Thanks!
next prev parent reply other threads:[~2020-06-03 19:10 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-03 11:40 [PATCH 0/9] x86/entry fixes Peter Zijlstra
2020-06-03 11:40 ` [PATCH 1/9] x86/entry: Fix irq_exit() Peter Zijlstra
2020-06-03 11:40 ` [PATCH 2/9] rcu: Fixup noinstr warnings Peter Zijlstra
2020-06-03 16:46 ` Paul E. McKenney
2020-06-03 17:13 ` Peter Zijlstra
2020-06-04 3:34 ` Paul E. McKenney
2020-06-04 6:02 ` Marco Elver
2020-06-04 14:14 ` Paul E. McKenney
2020-06-04 8:05 ` Peter Zijlstra
2020-06-04 14:17 ` Paul E. McKenney
2020-06-15 15:30 ` Peter Zijlstra
2020-06-15 15:52 ` Paul E. McKenney
2020-06-15 16:06 ` Peter Zijlstra
2020-06-15 15:49 ` Peter Zijlstra
2020-06-15 15:55 ` Peter Zijlstra
2020-06-15 16:24 ` Peter Zijlstra
2020-06-15 17:14 ` Paul E. McKenney
2020-06-15 18:33 ` Peter Zijlstra
2020-06-15 18:59 ` Paul E. McKenney
2020-06-15 20:00 ` Paul E. McKenney
2020-06-19 22:15 ` Paul E. McKenney
2020-06-23 20:46 ` Peter Zijlstra
2020-06-23 21:44 ` Paul E. McKenney
2020-06-24 7:52 ` Peter Zijlstra
2020-06-24 13:03 ` Paul E. McKenney
2020-06-03 11:40 ` [PATCH 3/9] x86/entry: __always_inline debugreg for noinstr Peter Zijlstra
2020-06-03 17:50 ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 11:40 ` [PATCH 4/9] x86/entry: __always_inline irqflags " Peter Zijlstra
2020-06-03 17:50 ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 11:40 ` [PATCH 5/9] x86/entry: __always_inline arch_atomic_* " Peter Zijlstra
2020-06-03 17:50 ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 11:40 ` [PATCH 6/9] x86/entry: Re-order #DB handler to avoid *SAN instrumentation Peter Zijlstra
2020-06-03 17:50 ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 11:40 ` [PATCH 7/9] lockdep: __always_inline more for noinstr Peter Zijlstra
2020-06-03 17:50 ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 11:40 ` [PATCH 8/9] x86/entry: __always_inline CR2 " Peter Zijlstra
2020-06-03 17:50 ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 11:40 ` [PATCH 9/9] x86/entry, cpumask: Provide non-instrumented variant of cpu_is_offline() Peter Zijlstra
2020-06-03 17:50 ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 12:00 ` [PATCH 0/9] x86/entry fixes Peter Zijlstra
2020-06-03 12:08 ` Peter Zijlstra
2020-06-03 12:08 ` Marco Elver
2020-06-03 12:18 ` Peter Zijlstra
2020-06-03 13:32 ` Marco Elver
2020-06-03 14:47 ` Marco Elver
2020-06-03 16:07 ` Peter Zijlstra
2020-06-03 17:26 ` Marco Elver
2020-06-03 18:16 ` Peter Zijlstra
2020-06-03 19:10 ` Marco Elver [this message]
2020-06-04 6:00 ` Marco Elver
2020-06-04 9:52 ` Marco Elver
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=CANpmjNPJ_vTyTYyrXxP2ei0caLo10niDo8PapdJj2s4-w_R3TA@mail.gmail.com \
--to=elver@google.com \
--cc=andreyknvl@google.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@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.