Re: [PATCH net v2] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

-*, +module +Paul.

On 2026-07-08 15:56:53 [+0200], To Petr Pavlu wrote:
> > One problem is that I'm not sure where the new rcu_barrier() call should
> > be placed. The prototype adds it before calling the module's exit
> > function. Would this actually fit all modules? From a quick look, I can
> > see that various modules call it at different points during their exit.
> 
> I don't know why you would use call_rcu() in your module_exit()
> (pointing to the same module). But you could have call_rcu() invoking
> kmem_cache_free() and destroying that cache (kmem_cache_destroy()) in
> your exit path. From that perspective it would make sense to flush all
> calls before invoking module_exit().

Paul, are the RCU callbacks always invoked in FIFO order?
If we put the module unmap into a call_rcu() (instead of the current
synchronize_rcu()) would we invoke the callback's of the module's
callback before the unmap of the module? Or is this not guaranteed due
callbacks on CPU0 vs CPU1 are executed in different order?

Because if the FIFO order is guaranteed then it would be cheapest
solution. But it would require a rcu_barrier() in kmem_cache_destroy()).

> > -- 
> > Thanks,
> > Petr

Sebastian