|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/2] xen/rcu: don't use stop_machine_run() for rcu_barrier()
On Mon, Feb 17, 2020 at 01:11:59PM +0100, Jürgen Groß wrote:
> On 17.02.20 12:49, Julien Grall wrote:
> > Hi Juergen,
> >
> > On 17/02/2020 07:20, Juergen Gross wrote:
> > > +void rcu_barrier(void)
> > > {
> > > - atomic_t cpu_count = ATOMIC_INIT(0);
> > > - return stop_machine_run(rcu_barrier_action, &cpu_count, NR_CPUS);
> > > + if ( !atomic_cmpxchg(&cpu_count, 0, num_online_cpus()) )
> >
> > What does prevent the cpu_online_map to change under your feet?
> > Shouldn't you grab the lock via get_cpu_maps()?
>
> Oh, indeed.
>
> This in turn will require a modification of the logic to detect parallel
> calls on multiple cpus.
If you pick my patch to turn that into a rw lock you shouldn't worry
about parallel calls I think, but the lock acquisition can still fail
if there's a CPU plug/unplug going on:
https://lists.xenproject.org/archives/html/xen-devel/2020-02/msg00940.html
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |