Hi Fred,
On Wed, Jun 1, 2022 at 10:24 AM Frederic Weisbecker <frederic@xxxxxxxxxx> 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.
Yes, it should. This initial prototype did not handle it and was
mentioned in one of the replies to the cover letter. However, in the
v2 of this, I am planning to use Paul's idea of sticking these in the
bypass list. It simplifies a lot of things which bypass handles
(hotplug, rcu_barrier, de-offload, etc).
Thanks,
- Joel
