On Fri, Apr 20, 2012 at 08:04:18PM +0100, Al Viro wrote: > Deferring the final pass after dropping ->mmap_sem is going to be > interesting; what would protect ->vm_next on those suckers? Locking > rules are already bloody complicated in mm/*; this will only add more > subtle fun. Note that right now both the dissolution of ->vm_next > list and freeing of VMAs happen under ->mmap_sem; changing that might > cost us a lot of headache... BTW, even leaving that aside, we have at least one definite deadlock (mainline, not on ->mmap_sem - see the mess in drivers/video/msm/mdp.c) and a possibility of other fun (e.g. any network filesystem that ends up triggering rtnl_lock() during umount is going to deadlock if you combine it with sch_atm.c mess where we do fget()/check/fput() in netlink message handling, close() from another thread racing with it and descriptor being the only thing that keeps that network fs alive past lazy umount or namespace dissolution). And then there's SCM_RIGHTS vs. drivers/vhost/net.c, which might or might not be deadlockable - I'm not familiar enough with that driver to tell right now. _If_ it had been ->mmap_sem alone, the things would be much simpler. There wouldn't be a problem, to start with - IMA stuff is not in the mainline and that's the only thing that really wants ->i_mutex in fput(); the few existing places that grab it in ->release() are racy anyway and need to be fixed with proper locking. -- 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
