Re: [PATCH 4/8] mm/slab: introduce kfree_rcu_nolock()

["Paul E. McKenney" <paulmck@kernel.org>]

On Tue, Apr 21, 2026 at 03:46:30PM -0700, Alexei Starovoitov wrote:
> On Thu Apr 16, 2026 at 2:10 AM PDT, Harry Yoo (Oracle) wrote:
> >  struct kfree_rcu_cpu {
> > +	// Objects queued on a lockless linked list, used to free objects
> > +	// in unknown contexts when trylock fails.
> > +	struct llist_head defer_head;
> > +
> > +	struct irq_work defer_free;
> > +	struct irq_work sched_delayed_monitor;
> > +	struct irq_work run_page_cache_worker;
> > +
> >  	// Objects queued on a linked list
> >  	struct rcu_ptr *head;
> >  	unsigned long head_gp_snap;
> > @@ -1333,12 +1341,99 @@ struct kfree_rcu_cpu {
> >  	struct llist_head bkvcache;
> >  	int nr_bkv_objs;
> >  };
> > +
> > +static void defer_kfree_rcu_irq_work_fn(struct irq_work *work);
> > +static void sched_delayed_monitor_irq_work_fn(struct irq_work *work);
> > +static void run_page_cache_worker_irq_work_fn(struct irq_work *work);
> > +
> > +static DEFINE_PER_CPU(struct kfree_rcu_cpu, krc) = {
> > +	.lock = __RAW_SPIN_LOCK_UNLOCKED(krc.lock),
> > +	.defer_head = LLIST_HEAD_INIT(defer_head),
> > +	.defer_free = IRQ_WORK_INIT(defer_kfree_rcu_irq_work_fn),
> > +	.sched_delayed_monitor =
> > +		IRQ_WORK_INIT_LAZY(sched_delayed_monitor_irq_work_fn),
> > +	.run_page_cache_worker =
> > +		IRQ_WORK_INIT_LAZY(run_page_cache_worker_irq_work_fn),
> > +};
> 
> I think kfree_rcu_cpu doesn't need to be per-cpu.
> It can be global llist with single irq_work for them all.

I would be quite nervous about that, but you might well be right, given
that this is a trylock-acquisition failure path.  Give or take people
and/or machines analyzing the code for potential denial-of-service
attacks.  :-/

> Not sure about sched_delayed_monitor/run_page_cache_worker.
> Do they have to be per-cpu ? Can all 3 share single irq_work?

On the other hand, if all CPUs are doing kfree_rcu() in even a semi-tight
loop, having them all unconditionally use global state is not going to
make for a fun time on large systems.  And there already are situations
where user code can make all CPUs to call_rcu() in a semi-tight loop,
so even if that is not yet the case for kfree_rcu(), past experience
indicates that it soon will be.

And noted on the desirability of call_rcu_nolock(), apologies for being
slow.

							Thanx, Paul