On Fri, Oct 31, 2025 at 01:54:27PM +0100, Christian Brauner wrote:
I agree that it's a regression in mount(8) conversion to new API, but this is not a fix.
Thanks for the review. Perhaps fixing this in |move_mount| isn't the best approach, and I don’t have a good solution yet.
Sorry, no. This restriction never made any sense in the old mount api and it certainly has no place in the new mount api. And it has been _years_ since the new mount api was released. Any fix is likely to break someone else that's already relying on that working.
Not quite... I agree that it makes little sense to do that on syscall level, but conversion of mount(8) to new API is a different story - that's more recent than the introduction of new API itself and it does create a regression on the userland side.
IIRC, the original rationale had been "what if somebody keeps clicking on something in some kind of filemangler inturdface and gets a pile of overmounts there?", but however weak that might be, it is an established behaviour of mount(2), with userland callers of mount(2) expecting that semantics.
Blind conversion to new API has changed userland behaviour. I would argue that it's a problem on the userland side, and the only question kernel-side is whether there is something we could provide to simplify the life of those who do such userland conversions. A move_mount(2) flag, perhaps, defaulting to what we have move_mount(2) do now?