On Fri, 2014-05-09 at 18:56 +0100, Al Viro wrote: > On Fri, May 09, 2014 at 12:10:03PM +0900, J. R. Okajima wrote: > > > > Dmitry Kasatkin: > > > Following patch replaces IMA usage of kernel_read() with special > > > version which skips security check that triggers kernel panic > > > when Apparmor and IMA appraisal are enabled together. > > > > I know this is related to exit(2), but this behaviour of IMA is related > > to open(2) too. > > When O_DIRECT is specified, some filesystems (for example, ext2) call > > do_blockdev_direct_IO() which acquires i_mutex. But > > IMA:process_measurement() already acquires i_mutex before kernel_read(). > > It causes a deadlock even if you replace kernel_read() by a simpler one. > > How can we stop reading the file from IMA? > > Disabling it would be a good start... And no, I'm not kidding - the mess > you are proposing is such that it's not at all obvious that this stuff > is worth the trouble.
Al, perhaps we didn't do a good job describing the different use case scenarios for the different aspects of the integrity subsystem. Are you interested in hearing about them? > Why the devil is it playing with ->i_mutex? IMA, that is. Its use for > data is absolutely fs-dependent. Again, filesystem is *NOT* required > to take ->i_mutex anywhere on the write path. At all. Agreed it shouldn't be taking the i_mutex. However, there was a lock ordering issue when writing extended attributes, which does take the i_mutex. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
