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

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



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.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.