On Wed, Jun 01, 2022 at 04:24:54PM +0200, Frederic Weisbecker wrote:
> On Thu, May 12, 2022 at 04:56:03PM -0700, Paul E. McKenney wrote:
> > On Thu, May 12, 2022 at 03:04:29AM +0000, Joel Fernandes (Google) wrote:
> > > + preempt_enable();
> > > +
> > > + if (debug_rcu_head_queue((void *)head)) {
> > > + // Probable double call_rcu(), just leak.
> > > + WARN_ONCE(1, "%s(): Double-freed call. rcu_head %p\n",
> > > + __func__, head);
> > > +
> > > + // Mark as success and leave.
> > > + return;
> > > + }
> > > +
> > > + // Queue to per-cpu llist
> > > + head->func = func;
> > > + llist_add(&head->llist_node, &rlp->head);
> >
> > Suppose that there are a bunch of preemptions between the preempt_enable()
> > above and this point, so that the current CPU's list has lots of
> > callbacks, but zero ->count. Can that cause a problem?
> >
> > In the past, this sort of thing has been an issue for rcu_barrier()
> > and friends.
>
> Speaking of, shouldn't rcu_barrier() flush all the lazy queues? I
> might have missed that somewhere in the patchset though.
It should, but Joel deferred rcu_barrier() handling for this initial
prototype. So be careful when playing with it. ;-)
Thanx, Paul
