> My apologies for the delay on this, I was traveling for a bit and > missed this issue while away. > > Looking quickly at the report, I don't believe this is a false positive. This is the mistake I made when I first watched the report. It should be a deadlock. > Looking at the IMA code, specifically the process_measurement() > function which is called from the security_mmap_file() LSM hook, I'm > not sure why there is the inode_lock() protected region. Mimi? > Roberto? My best guess is that locking the inode may have been > necessary before we moved the IMA inode state into the inode's LSM > security blob, but I'm not certain. > > Mimi and Roberto, can we safely remove the inode locking in > process_measurement()? It would be better if IMA could avoid acqurie inode_lock(). If not, then we may need to consider solutions I mentioned in my previous reply.
