Hi Krisztian, (Reposting my response as it never made it to the mailing list.) > Hi, > > I've run into a reliably reproducible deadlock/reversed locking order > bug involving overlayfs and IMA-enabled filesystems. It can be > triggered very simply by constructing a read-write overlay using > lower, upper, and work directories all on IMA-enabled filesystems. > With such a setup simply trying to create an empty file by touch > triggers the bug. Retrying the same thing with the upper and work > directories on an IMA-ignored filesystem (for instance on a tmpfs) > avoids the problem. From the stack trace it looks like we get into the > deadlock when IMA tries to update the extended attribute for the newly > created file which calls thru vfs into overlayfs. Right, ima_file_free(), which is called from __fput(), writes the file hash as a security xattr. This seems to trigger the overlay's writing of the xattr. Testing if the S_IMA flag is set before taking the i_mutex would probably prevent the lockdep. > The setup is arguably a corner case (I don't think there are hoards of > folks trying to mix overlays with IMA), but I'm not sure if the same > problem could be triggered by something less pathological. Deferring __fput() was introduced back in 2012 in order for IMA to take the i_mutex. So it shouldn't be a problem. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
