Re: [Xen-devel] [PATCH v2 3/3] xen: hook up UBSAN with CONFIG_UBSAN

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.10.17 at 16:38, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 09/10/17 15:36, Jan Beulich wrote:
>>>>> On 09.10.17 at 16:11, <wei.liu2@xxxxxxxxxx> wrote:
>>> --- a/xen/common/ubsan/ubsan.c
>>> +++ b/xen/common/ubsan/ubsan.c
>>> @@ -10,13 +10,18 @@
>>>   *
>>>   */
>>>  
>>> -#include <linux/bitops.h>
>>> -#include <linux/bug.h>
>>> -#include <linux/ctype.h>
>>> -#include <linux/init.h>
>>> -#include <linux/kernel.h>
>>> -#include <linux/types.h>
>>> -#include <linux/sched.h>
>>> +#include <xen/spinlock.h>
>>> +#include <xen/percpu.h>
>>> +
>>> +#define __noreturn    noreturn
>>> +#define pr_err(...) printk(XENLOG_ERR __VA_ARGS__)
>>> +struct xen_ubsan { int in_ubsan; };
>>> +static DEFINE_PER_CPU(struct xen_ubsan[1], in_ubsan);
>>> +#undef current
>>> +#define current this_cpu(in_ubsan)
>>> +#define dump_stack dump_execution_state
>>> +#define u64 long long unsigned int
>>> +#define s64 long long int
>> Wasn't it agreed to make these uint64_t and int64_t?
> 
> Sadly that doesn't work, because of the explicit casts used in the
> sprintf().
> 
> Depending on how much we tolerate modifying the Linux code, these can be
> removed if we change to using appropriate PRIx64 formatters instead. 
> However, I would prefer to avoid changing the Linux code if possible.

Ah, yes, that's good enough a reason. Together with Julien's
reply then
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel