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 > inode_init_always) > > 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 > inode->i_security.... 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. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
