On Thu, Jan 12, 2017 at 05:18:12AM +1300, Eric W. Biederman wrote: > > When I look at what propagate_mount_busy is trying to do and I look > at the code closely I discover there is a great disconnect between the > two. In the ordinary non-propagation case propagate_mount_busy has > been verifying that there are no submounts and that there are no > extraneous references on the mount. > > For mounts that the unmount would propagate to propagate_mount_busy has > been verifying that there are no extraneous references only if there > are no submounts. Which is nonsense. ... because? > Thefore rework the logic in propgate_mount_busy so that for each > mount it examines it considers that mount busy if that mount has > children or if there are extraneous references to that mount. > > While this check was incorrect we could leak mounts instead of simply > failing umount. What do you mean, leak? We ended up not unmounting them, and they stayed around until umount of whatever they'd been shadowed by/slipped under had exposed them and they got explicitly unmounted. This is not a leak in a sense of "data structure is unreachable and will never be freed", unlike the one your previous version had introduced. Your change might very well be a nicer behaviour - or a DoS in making. But it really deserves more detailed rationale than that and yes, it is a user-visible change. With rather insane userland setups in that area (*cough* systemd *cough* docker), it's _not_ obviously correct. -- 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
