On Wed, Dec 18, 2024 at 01:16:15PM -0800, Song Liu wrote: > inode->i_security needes to be freed from RCU callback. A rcu_head was > added to i_security to call the RCU callback. However, since struct inode > already has i_rcu, the extra rcu_head is wasteful. Specifically, when any > LSM uses i_security, a rcu_head (two pointers) is allocated for each > inode. > > Rename i_callback to inode_free_callback and call security_inode_free_rcu > from it to free i_security so that a rcu_head is saved for each inode. > Special care are needed for file systems that provide a destroy_inode() > callback, but not a free_inode() callback. Specifically, the following > logic are added to handle such cases: > > - XFS recycles inode after destroy_inode. The inodes are freed from > recycle logic. Let xfs_inode_free_callback() call inode_free_callback. NACK. That's a massive layering violation. LSMs are VFS layer functionality. They *must* be removed from the VFS inode before ->destroy_inode() is called. If a filesystem supplies ->destroy_inode(), then it -owns- the inode exclusively from that point onwards. All VFS and 3rd party stuff hanging off the inode must be removed from the inode before ->destroy_inode() is called. Them's the rules, and hacking around LSM object allocation/freeing to try to handle how filesystems manage inodes -underneath- the VFS is just asking for problems. LSM object management needs to be handled entirely by the generic LSM VFS hooks, not tightly coupled to VFS and/or low level filesystem inode lifecycle management. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
