Re: lsm sb_delete hook, was Re: [PATCH 4/7] vfs: Convert sb->s_inodes iteration to super_iter_inodes()
From: Christian Brauner <brauner@kernel.org>
Date: 2024-10-04 07:21:25
Also in:
linux-bcachefs, linux-fsdevel, linux-xfs
On Fri, Oct 04, 2024 at 10:46:27AM GMT, Dave Chinner wrote:
On Thu, Oct 03, 2024 at 06:17:31PM +0200, Jan Kara wrote:quoted
On Thu 03-10-24 23:59:51, Dave Chinner wrote:quoted
As for the landlock code, I think it needs to have it's own internal tracking mechanism and not search the sb inode list for inodes that it holds references to. LSM cleanup should be run before before we get to tearing down the inode cache, not after....Well, I think LSM cleanup could in principle be handled together with the fsnotify cleanup but I didn't check the details.I'm not sure how we tell if an inode potentially has a LSM related reference hanging off it. The landlock code looks to make an assumption in that the only referenced inodes it sees will have a valid inode->i_security pointer if landlock is enabled. i.e. it calls landlock_inode(inode) and dereferences the returned value without ever checking if inode->i_security is NULL or not. I mean, we could do a check for inode->i_security when the refcount is elevated and replace the security_sb_delete hook with an security_evict_inode hook similar to the proposed fsnotify eviction from evict_inodes(). But screwing with LSM instructure looks .... obnoxiously complex from the outside...
Imho, please just focus on the immediate feedback and ignore all the extra bells and whistles that we could or should do. I prefer all of that to be done after this series lands.