|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as required
Stefano Stabellini writes ("[PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
required"):
> Use DECLARE_BOUNDS and the two static inline functions that come with it
> for comparisons and subtractions of:
>
> __2M_rwdata_start, __2M_rwdata_end, __end_vpci_array,
> __start_vpci_array, _stextentry, _etextentry, __trampoline_rel_start,
> __trampoline_rel_stop, __trampoline_seg_start, __trampoline_seg_stop
> __per_cpu_start, __per_cpu_data_end
>
> possible to use the provided static inline functions.
> M3CM: Rule-18.2: Subtraction between pointers shall only be applied to
> pointers that address elements of the same array.
Hi. I picked one of these to briefly look at the detail of and I
spotted this:
> @@ -49,7 +50,7 @@ static void _free_percpu_area(struct rcu_head *head)
> {
> struct free_info *info = container_of(head, struct free_info, rcu);
> unsigned int cpu = info->cpu;
> - char *p = __per_cpu_start + __per_cpu_offset[cpu];
> + char *p = (char *)__per_cpu_start + __per_cpu_offset[cpu];
This is dangerous because it turns __per_cpu_start which is a magic
linker symbol pointer into one which you might try to compare with
other pointers.
I can't see from your patch what else is done to `p'. Something ought
to be done to prevent future programmers from comparing p to other
pointers.
Some extended comment, or something, is likely to be needed every time
you introduce a cast.
> free_xenheap_pages(p, PERCPU_ORDER);
JOOI, why does free_xenheap_pages not take a void* ?
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |