On Wed, Jan 11, 2017 at 03:27:05PM +1300, Eric W. Biederman wrote: > The design is for the parent mount to hold a reference to the submounts. > And when the reference on the parent drops to 0. The references on > all of the submounts will also be dropped. Parent does _not_ hold any references to submounts. Never had. What happens in umount_tree() is that any surviving submounts a) are inserted into ->mnt_pins of parent, but not into unmounted. a) have the reference to parent dropped. When the last reference to parent gets dropped, all remaining submounts get unhashed and when we get to cleanup_mnt() on parent, ->mnt_pins gets pulled. Which does dput() on (ex)mountpoints and mntput() on those submounts. > I was hoping to read the code and point it out to you quickly, but I am > not seeing it now. I am wondering if in all of the refactoring of that > code something was dropped/missed :( > > Somewhere there is supposed to be the equivalent of: > pin_insert_group(&p->mnt_umount, &p->mnt_parent->mnt, &unmounted); > when we unhash those mounts because the last count has gone away. > Either it is very sophisticated or I am missing it. Grr.... What you are missing is that they never end up on 'unmounted' - only on ->mnt_pin of parent. It's the same pin_insert_group() in umount_tree() as for everything else, the only difference being that it does _not_ get kicked out on the namespace_unlock(). -- 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
