Re: [PATCH v1.1 2/3] xen/sched: fix theoretical races accessing vcpu->dirty_cpu

[Julien Grall <julien@xxxxxxx>]

On 02/05/2020 13:34, Julien Grall wrote:
> > > > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> > > > index 195e7ee583..81628e2d98 100644
> > > > --- a/xen/include/xen/sched.h
> > > > +++ b/xen/include/xen/sched.h
> > > > @@ -844,7 +844,7 @@ static inline bool is_vcpu_dirty_cpu(unsigned 
> > > > int cpu)
> > > >   static inline bool vcpu_cpu_dirty(const struct vcpu *v)
> > > >   {
> > > > -    return is_vcpu_dirty_cpu(v->dirty_cpu);
> > > > +    return is_vcpu_dirty_cpu(read_atomic((unsigned int 
> > > > *)&v->dirty_cpu));
> > > Is the cast necessary?
> > Yes, that was the problem when building for ARM I encountered.
> >
> > read_atomic() on ARM has a local variable of the same type as the
> > read_atomic() parameter for storing the result. Due to the const
> > attribute of v this results in assignment to a read-only variable.
> Doh, we should be able to read from a const value without. So I would 
> argue this is a bug in the read_atomic() implementation on Arm. I will 
> try to come up with a patch.
I have just sent a series [1] to address the issue reported here and a 
few more.
Cheers,

[1] <20200502160700.19573-1-julien@xxxxxxx>

--
Julien Grall