Re: options KUBSAN on UEFI machine

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 29/07/2019 à 00:06, Kamil Rytarowski a écrit :
> On 28.07.2019 16:09, Maxime Villard wrote:
> > Le 27/07/2019 à 14:14, Kamil Rytarowski a écrit :
> > > On 25.07.2019 06:39, Masanobu SAITOH wrote:
> > > >    Hi.
> > > >
> > > >    I have two UEFI based machines. I noticed both of them didn't boot
> > > > with KUBSAN. After loading kernel, the video console is cleared,
> > > > the cursol went upper left and then hang. I couldn't see the
> > > > NetBSD's copyright message.
> > > >
> > > >    Is this known problem?
> > >
> > > I have got a local problem that I'm not successfully booting my amd64
> > > desktop with enabled i915 DRM KMS Framebuffer driver.
> >
> > This could be that the KMS driver itself is generating a KUBSAN message.
> > So printf() gets called, it lands back in the KMS driver to print the
> > actual thing, which triggers again a KUBSAN message, so printf() gets
> > called again, and so on. It likely dies in a deadlock on whatever mutex
> > we take along the way.
> >
> > In Masanobu's case, it is probably that the UEFI boot path triggers a
> > KUBSAN message, printf() gets called, but the console hasn't yet been
> > initialized, so it faults and dies there.
>
> What are the best workarounds for these problems?

We could change the sanitizers not to call printf(), but instead log the
event in an internal (lockless) buffer, and then rely on a kthread that
regularly scans the buffer and calls printf() to print the messages. This
will eliminate the deadlocks, since the kthread is in its own context.

In Masanobu's case, the UEFI boot path will cause events to be logged in
the internal buffer, and they will get displayed later in the boot
procedure when the kthread starts.

But then there will be some latency between when a sanitizer fires and
when the warning gets displayed.