Hello, so I've been tracking down a problem where sometimes umount failed to umount my test filesystem (-EBUSY) for no apparent reason. Eventually I've come across a reasonably reproducible testcase which allowed me to investigate more. I've found the reason for failing umount is increased mnt_count and that is caused by outstanding fsnotify events (i.e. events that have been generated but not yet read from notification fd) - some types of events seem to do path_get() on the path where the event happened. In my case it was some Gnome desktop daemon that tried to watch the test fs and wasn't able to consume events fast enough so it wasn't possible to umount the filesystem until the daemon consumed all the events. And the nasty thing is that this is *really* hard to detect (I had to do quite a bit of kernel instrumentation to find out what's going on). Another sad fact is that fsnotify does path_get() only to accomodate the case when fanotify is used (fanotify has that "creative" feature that it returns open file descriptor with each event so it needs struct path for creating that descriptor). I find this behavior rather anoying but I don't see an easy fix so I'm sending my findings here to check whether someone has some idea... Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
