Port-amd64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: options KUBSAN on UEFI machine



On 29.07.2019 08:05, Maxime Villard wrote:
> 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.

I can do it differently:

Add a kernel option that will:

1. Log into a local buffer without synchronization.
2. Register ubsan kernel module.
3. Register from the kernel module a new ddb command to flush the buffer.

This should be good enough for early boot issues and simple to implement.

Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index