On Mon, Nov 14, 2011 at 10:13:11AM -0500, Eric Paris wrote:
> The only way this can happen is if the filesystem is creating inodes
> and not calling security_inode_alloc() (which should be done in
> I can only guess (and believe me it is a complete wild guess after
> looking at grep for 5 seconds) it has something to do with the XFS
> __releases() function which does some weirdness in the case of a
> failed call to inode_init_always().
Do you mean xfs_iget_cache_hit?
> The only other option is an FS somehow still uses an inode after
> __destroy_inode(), but I'd assume that would land you in other
> troubles. In either case, I'm hard pressed to blame SELinux/LSM,
> since the VFS does appear to be hooked in the right places
> (inode_init_alwasys and __destroy_inode) to set and unset
XFS inodes have a longer life time than VFS inodes they still
hang around after ->destroy_inode, and if we manage to reuse them
we'll call inode_init_always on them manually. The error handling
there is nasty - basically we try to move it back into the state
before we tried to reuse it, return an error to userspace and then
expect the inode to either get reclaimed, or that we have enough
memory next time someone tries to reuse it. Note that the only
way for it to fail is if security_inode_alloc fails, so on normal
non-LSM systems it won't ever fail.
I can't really see an issue with i_security lifetimes from a quick
look over the code, though.