Re: [Xen-devel] [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as required

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 6 Mar 2019, Jan Beulich wrote:
> >>> On 05.03.19 at 23:38, <sstabellini@xxxxxxxxxx> wrote:
> > @@ -600,7 +602,9 @@ static void noinline init_done(void)
> >      unregister_init_virtual_region();
> >  
> >      /* Zero the .init code and data. */
> > -    for ( va = __init_begin; va < _p(__init_end); va += PAGE_SIZE )
> > +    for ( va = (char *)__init_begin;
> > +          init_lt(va, __init_end);
> > +          va += PAGE_SIZE )
> >          clear_page(va);
> 
> At the example of this - is casting away of const-ness not also a
> potential certification hindrance?

Darn, well spotted! No, it is not permitted (Rule 11.8).
In this case const is not correct because we actually modify the object
few lines below:

  base->priv = 1;


This is problematic. We have also the following instances in this series
to deal with:

xen/arch/arm/percpu.c:_free_percpu_area
  char *p = (char *)__per_cpu_start + __per_cpu_offset[cpu];

xen/arch/x86/percpu.c:_free_percpu_area
  char *p = (char *)__per_cpu_start + __per_cpu_offset[cpu];

xen/arch/x86/setup.c:init_done
  for ( va = (char *)__init_begin; init_lt(va, __init_end); va += PAGE_SIZE )

xen/arch/x86/alternative.c:apply_alternatives
  for ( a = base = (struct alt_instr *)start; alt_instr_lt(a, end); a++ )


In all these cases we actually end up modifying the object. I suggest
we remove the const from either __DECLARE_BOUNDS (so from everywhere),
or just for per_cpu, init, and alt_instr by introducing another MACRO.

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