On Wed, Apr 08, 2015 at 08:19:27AM +1000, Dave Chinner wrote: > That's kinda nasty, and it has no documentation explaining when or > why we'd need to drop the i_mutex. How are we supposed to know if we > need to drop the i_mutex or not? We need to drop it if we hold it, pretty easy. > What happens if the upper VFS > layers change or we have a multiple call paths that have different > i_mutex contexts (i.e. one holds, another doesn't)? We avoid this in the VFS, as everytime we had it filesystems were getting it wrong. However you have a point in that we should probably have asserts that the right locks are held. > Which makes me wonder - is this layout breaking stuff at the right > layer? We can't do it in the VFS as it needs to be atomic vs the lock that protects write in ->write and ->fallocate, which is only taken in the filesystem. For ->setattr in theory we could do it in the VFS, but if the other callers can't do it in the VFS that will just lead to code duplication. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
