[git pull] mount fixes

[git pull] mount fixes

[Al Viro]

The following changes since commit a82ba839915926f8713183fd023c6d9357bae26c:

  Merge tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2025-05-30 15:04:11 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull-fixes

for you to fetch changes up to 12f147ddd6de7382dad54812e65f3f08d05809fc:

  do_change_type(): refuse to operate on unmounted/not ours mounts (2025-06-07 01:37:56 -0400)

----------------------------------------------------------------
mount-related bugfixes

this cycle regression (well, bugfix for this cycle bugfix for v6.15-rc1 regression)
	do_move_mount(): split the checks in subtree-of-our-ns and entire-anon cases
	selftests/mount_setattr: adapt detached mount propagation test
v6.15	fs: allow clone_private_mount() for a path on real rootfs
v6.11	fs/fhandle.c: fix a race in call of has_locked_children()
v5.15	fix propagation graph breakage by MOVE_MOUNT_SET_GROUP move_mount(2)
v5.15	clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns
v5.7	path_overmount(): avoid false negatives
v3.12	finish_automount(): don't leak MNT_LOCKED from parent to child
v2.6.15	do_change_type(): refuse to operate on unmounted/not ours mounts

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

----------------------------------------------------------------
Al Viro (7):
      fs/fhandle.c: fix a race in call of has_locked_children()
      path_overmount(): avoid false negatives
      finish_automount(): don't leak MNT_LOCKED from parent to child
      fix propagation graph breakage by MOVE_MOUNT_SET_GROUP move_mount(2)
      do_move_mount(): split the checks in subtree-of-our-ns and entire-anon cases
      clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns
      do_change_type(): refuse to operate on unmounted/not ours mounts

Christian Brauner (1):
      selftests/mount_setattr: adapt detached mount propagation test

KONDO KAZUMA(近藤　和真) (1):
      fs: allow clone_private_mount() for a path on real rootfs

 fs/namespace.c                                     | 113 +++++++++++++--------
 include/linux/mount.h                              |   3 +-
 .../selftests/mount_setattr/mount_setattr_test.c   |  17 +---
 3 files changed, 74 insertions(+), 59 deletions(-)

Re: [git pull] mount fixes

[pr-tracker-bot]

The pull request you sent on Sun, 8 Jun 2025 18:24:09 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull-fixes

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/35b574a6c2279fe47d13ffafb8389f1adc87a1d1

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

[PATCHES][RFC][CFT] mount fixes

[Al Viro]

	Several regression fixes of varying severity; live in
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git, individual
patches in followups.  Help with testing and reviewing would be very
welcome.

1) attach_recursive_mnt() slowdown - severe in some pathological cases.
This cycle regression, fortunately trivial to fix.  Underlying mechanism
of slowdown (bypassed by that fix) is due to bad semantics of skip_mnt_tree(),
but that's a separate story.
The case with severe slowdown is mounting on top of a long chain of overmounts,
all peers with each other.  Ends up being time-quardatic by the depth of chain,
easily triggers softlockup warnings.  Since the slow part is under mount_lock,
all pathname resolution pretty much stops for the duration.  Kudos for catching
that to "Lai, Yi" <yi1.lai@linux.intel.com>...

2) reparenting in propagate_umount() should *NOT* be done to mounts that are
themselves going to be taken out.  I'd even put "<argument> is not to going
away, and it overmounts the top of a stack of mounts that are going away"
right on top of reparent()...  and lost the logics in its caller that used
to check that at some point during reshuffling the queue ;-/  This cycle's
regression and that one is not just a slowdown - in some cases it might end
up as data corruptor.  Trivial to fix...

3) permission checks for --make-{shared,slave,private,unlinkable} (i.e.
MS_{SHARED,...} in mount(2) flags) ended up being too restrictive.
The checks used to be too weak until the last cycle.  Then they were
made stricter - basically to "mount is a part of our namespace and we have
admin permissions there".  Turns out that CRIU userland depended upon the
weak^Wabsent checks we used to have there before.  Sane replacement that
would suffice for them is "mount is a part of *SOME* namespace that we have
admin permissions for".  Last cycle userland regression...

4) change_mnt_propagation() slowdown in some cases.  On umount we want all
victims out of propagation graph and propagation between the surviving mounts
to be unchanged.  So if victim used to have slaves, they need to be transfered
to its peer (if any) or master.  In case when victim had many peers, all
taken out by that umount(), that ended up with all its slaves being gradually
transferred between all peers until we finally ran out of those.  It can
easily lead to quadratic time.  The patch in -rc1 switched that to "just
find where they'll end up upfront, and move them once", which eliminated
that... except that I hadn't noticed that on massage of change_mnt_propagation()
we ended up calculating the place where they'd be transferred in cases
when there had been nothing to transfer.  With obvious effects when there
had been a large peer group entirely taken out, with not a single slave between
them.  The minimal fix ("call propagation_source() only if we are going to
use its return value") is enough to recover in all cases.
Longer term we should kick all victims out of propagation graph at once
and I have that plotted out, but that's for the next merge window; for
now the minimal obvious fix is good enough.

[git pull] mount fixes

[Al Viro]

(collected *-by and slightly cleaned the text in commit message of [3/4]; otherwise
identical to what had been posted and sat in #fixes)

The following changes since commit 8742b2d8935f476449ef37e263bc4da3295c7b58:

  Merge tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2025-08-12 12:10:33 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull-fixes

for you to fetch changes up to fb924b7b8669503582e003dd7b7340ee49029801:

  change_mnt_propagation(): calculate propagation source only if we'll need it (2025-08-19 12:05:59 -0400)

----------------------------------------------------------------
fixes for several recent mount-related regressions

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

----------------------------------------------------------------
Al Viro (4):
      fix the softlockups in attach_recursive_mnt()
      propagate_umount(): only surviving overmounts should be reparented
      use uniform permission checks for all mount propagation changes
      change_mnt_propagation(): calculate propagation source only if we'll need it

 fs/namespace.c | 41 ++++++++++++++++++++++-------------------
 fs/pnode.c     | 10 ++++++----
 2 files changed, 28 insertions(+), 23 deletions(-)

Re: [git pull] mount fixes

[Linus Torvalds]

On Tue, 19 Aug 2025 at 09:12, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> (collected *-by and slightly cleaned the text in commit message of [3/4]; otherwise
> identical to what had been posted and sat in #fixes)

Minor note relating to my workflow: I almost overlooked this pull
request, because it was a continuation of a thread with the subject
"[PATCHES][RFC][CFT]", and then shows up in my mailbox as part of that
thread.

So even though you had removed those RFC/CFT notes from the subject
line, that ended up being not entirely obvious in my MUA, and I was
about to archive the email before I started looking closer.

Now, this time I obviously caught it, but in general it might be safer
to make it more obvious that it has gone from a RFC to a "this is a
real pull".  Not being threaded is obviously one way, or just a bigger
note to make it more obvious.

And hey, this is not generally a huge problem. I could miss emails for
other random reasons like flaky spam detectors or just plain
(hopefully rare) incompetence on my part.

So obviously the general fix to "why didn't Linus pull" is to send me
a follow-up email reminding me about missed pull requests, but I
thought I'd mention this as a "avoid potential delays and confusion"
thing.

              Linus

Re: [git pull] mount fixes

[pr-tracker-bot]

The pull request you sent on Tue, 19 Aug 2025 17:12:28 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull-fixes

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b19a97d57c15643494ac8bfaaa35e3ee472d41da

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html