Re: [PATCH] ubsan: Introduce CONFIG_UBSAN_FATAL to panic on UBSAN failure

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 28/11/2023 5:00 pm, Michal Orzel wrote:
> Hi Julien,
>
> On 28/11/2023 17:14, Julien Grall wrote:
>>
>> Hi Michal,
>>
>> On 27/11/2023 15:41, Michal Orzel wrote:
>>> Introduce the CONFIG_UBSAN_FATAL option to cater to scenarios where prompt
>>> attention to undefined behavior issues, notably during CI test runs, is
>>> essential. When enabled, this option causes Xen to panic upon detecting
>>> UBSAN failure (as the last step in ubsan_epilogue()).
>> I have mixed opinions on this patch. This would be a good one if we had
>> a Xen mostly free from UBSAN behavior. But this is not the case at least
>> on arm32. So we would end up to stop at the first error. IOW, we would
>> need to fix the first error before we can see the next one.
> Well, this patch introduces a config option disabled by default.
> If we end up enabling it for CI for reasons* stated by Andrew, then the 
> natural way
> of handling such issues is to do the investigation locally. Then, you are not 
> forced
> to select this option and you can see all the UBSAN issues if you want.
>
>> So I feel it would be best if the gitlab CI jobs actually check for
>> USBAN in the logs and fail if there are any. With that, we can get the
>> full list of UBSAN issues on each job.
> Well, I prefer Andrew suggestion (both [1] and on IRC), hence this patch.
>
> *my plan was to first fix the UBSAN issues and then enable this option for CI.
>
> [1] 
> https://lore.kernel.org/xen-devel/7421ddfd-8947-4fe1-93a6-dc25a4aa8bbc@xxxxxxxxxx/T/#t

Searching logs is never reliable.

Even within gitlab, we've had error upon error getting the console logs
out reliably, and it's even worse on real hardware.

This is an optional thing, but for people who want it, it's very highly
desirable.

~Andrew