On Fri, Jul 04, 2025 at 11:39:16AM +1000, NeilBrown wrote: > On Fri, 04 Jul 2025, Al Viro wrote: > > On Mon, Jun 16, 2025 at 12:49:51PM +1000, NeilBrown wrote: > > > > > The reality is that ->sysctl does not need rcu protection. There is no > > > concurrent update except that it can be set to NULL which is pointless. > > > > I would rather *not* leave a dangling pointer there, and yes, it can > > end up being dangling. kfree_rcu() from inside the ->evict_inode() > > may very well happen earlier than (also RCU-delayed) freeing of struct > > inode itself. > > In that case could we move the proc_sys_evict_inode() call from > proc_evict_inode() to proc_free_inode(), and replace kfree_rcu() with > kfree()? proc_free_inode() can be called from softirq context, so we'd need to touch all sysctl_lock users for that. Definitely a larger patch that way, if nothing else...
