Re: [Xen-devel] [PATCH v10 4/6] xen/x86: use DEFINE_SYMBOL as required

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.02.19 at 20:23, <sstabellini@xxxxxxxxxx> wrote:
> On Tue, 26 Feb 2019, Ian Jackson wrote:
>> Stefano Stabellini writes ("[PATCH v10 4/6] xen/x86: use DEFINE_SYMBOL as 
>> required"):
>> > Use SYMBOLS_SUBTRACT and SYMBOLS_COMPARE in cases of comparisons and
>> > subtractions of:
>> ...
>> > Use explicit casts to uintptr_t when it is not possible to use the
>> > provided static inline functions.
>> 
>> Why is it not possible ?  You write:
>> 
>> > +/*
>> > + * Cannot use DEFINE_SYMBOL because of the way they are passed to
>> > + * apply_alternatives.
>> > + */
>> >  extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
>> 
>> But I don't know why you can't pass a `struct abstract_alt_instr*' to
>> apply_alternatives.
>> 
>> IMO it should be strictly forbidden to ever write this formulation, as
>> you have above.  See my proposed rule comment for DEFINE_SYMBOL.
>> 
>> Even if you can't use the macros at some particular calculation site,
>> you should still ensure that ..._end has a different type, to make
>> sure that no unsafe uses escape.
> 
> Unfortunately __apply_alternatives is called from
> __apply_alternatives_multi_stop, where it would be fine to use struct
> abstract_alt_instr*, and also from apply_alternatives which in a
> xen/common interface called from xen/common/livepatch.c and doesn't work
> with linker symbols AFAICT.

As Ian says, it's only a matter of correctly defining the type of "end" at
the call site.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel