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. What we can do is WRITE_ONCE() to set it to NULL on the evict_inode side and READ_ONCE() in the proc_sys_compare(). The reason why the latter is memory-safe is that ->d_compare() for non-in-lookup dentries is called either under rcu_read_lock() (in which case observing non-NULL means that kfree_rcu() couldn't have gotten to freeing the sucker) *or* under ->d_lock, in which case the inode can't reach ->evict_inode() until we are done. So this predicate is very much relevant. Have that fucker called with neither rcu_read_lock() nor ->d_lock, and you might very well end up with dereferencing an already freed ctl_table_header.
