On Sun, 2017-01-08 at 15:52 +0100, Christoph Hellwig wrote: > On Sun, Jan 08, 2017 at 09:48:44AM -0500, Mimi Zohar wrote: > > IMA takes the i_rwsem (fomerly i_mutex) before reading the file to > > synchronize calculating the file hash and validating the file's > > hash/signature stored as security.ima xattr > > Well, it shouldn't do that. In the I/O path i_rwsem is up to the > fs to use. Various other file systems also take it internally for > reads, although mostly only for direct I/O. Hey, that's not really true: the inode lock (i_rwsem) is used in all sorts of generic places, including generic_file_write_iter(). That's, I think, why ima is using it to try to prevent writes while it measures the file. > So the answer here is that ima needs to stop playing with i_rwsem. Isn't there a happy medium? most sensible filesystems will allow shared reading (unless they want to tank performance) so we can rely on the fact that even if a fs does use i_rwsem internally on the read path, it will have to be shared. So simply replacing the inode_lock() in ima with inode_lock_shared() should do what ima wants and not interact badly even if the underlying FS uses i_rwsem. If there's ever a FS that takes it exclusively in the read path, ima can simply blacklist it. James -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
