[PATCH] fs/mount_setattr: always cleanup mount_kattr

[PATCH] fs/mount_setattr: always cleanup mount_kattr

[Christian Brauner]

Make sure that finish_mount_kattr() is called after mount_kattr was
succesfully built in both the success and failure case to prevent
leaking any references we took when we built it. So far we returned
early if path lookup failed thereby risking to leak an additional
reference we took when building mount_kattr when an idmapped mount was
requested.

Cc: linux-fsdevel@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
---
Hey Linus,

This contains a simple fix to get rid of a pointless refcount bump when
requesting an idmapped mount after we built mount_kattr but in case we
failed too lookup the target path and error out early without calling
finish_mount_kattr().

Would you be ok with applying this fix directly? I'm happy to send a pr
too of course but I wasn't sure if that was worth it as there's not much
explaining to do in the pr message for this one, I think.

This hasn't been in -next but given that it hasn't been updated in about
a week I don't think it makes much sense to delay this. The fix should
hopefully be straightforward.
Fstests and mount_setattr selftests pass without regressions
(showing only relevant tests):

SECTION       -- xfs
RECREATING    -- xfs on /dev/loop4
FSTYP         -- xfs (debug)
PLATFORM      -- Linux/x86_64 f2-vm 5.16.0-rc7-fs-mount-setattr-fixes-1a24ab33373b #33 SMP PREEMPT Thu Dec 30 15:55:39 UTC 2021
MKFS_OPTIONS  -- -f -f /dev/loop5
MOUNT_OPTIONS -- /dev/loop5 /mnt/scratch

generic/633 5s ...  25s
generic/644 18s ...  14s
generic/645 80s ...  75s
generic/656 3s ...  15s
xfs/152 63s ...  70s
xfs/153 43s ...  46s
Ran: generic/633 generic/644 generic/645 generic/656 xfs/152 xfs/153
Passed all 6 tests

SECTION       -- ext4
RECREATING    -- ext4 on /dev/loop4
FSTYP         -- ext4
PLATFORM      -- Linux/x86_64 f2-vm 5.16.0-rc7-fs-mount-setattr-fixes-1a24ab33373b #33 SMP PREEMPT Thu Dec 30 15:55:39 UTC 2021
MKFS_OPTIONS  -- -F -F /dev/loop5
MOUNT_OPTIONS -- -o acl,user_xattr /dev/loop5 /mnt/scratch

generic/633 25s ...  18s
generic/644 14s ...  4s
generic/645 75s ...  59s
generic/656 15s ...  8s
Ran: generic/633 generic/644 generic/645 generic/656
Passed all 4 tests

SECTION       -- btrfs
RECREATING    -- btrfs on /dev/loop4
FSTYP         -- btrfs
PLATFORM      -- Linux/x86_64 f2-vm 5.16.0-rc7-fs-mount-setattr-fixes-1a24ab33373b #33 SMP PREEMPT Thu Dec 30 15:55:39 UTC 2021
MKFS_OPTIONS  -- -f /dev/loop5
MOUNT_OPTIONS -- /dev/loop5 /mnt/scratch

btrfs/245 9s ...  10s
generic/633 18s ...  21s
generic/644 4s ...  4s
generic/645 59s ...  62s
generic/656 8s ...  8s
Ran: btrfs/245 generic/633 generic/644 generic/645 generic/656
Passed all 5 tests

SECTION       -- xfs
=========================
Ran: generic/633 generic/644 generic/645 generic/656 xfs/152 xfs/153
Passed all 6 tests

SECTION       -- ext4
=========================
Ran: generic/633 generic/644 generic/645 generic/656
Passed all 4 tests

SECTION       -- btrfs
=========================
Ran: btrfs/245 generic/633 generic/644 generic/645 generic/656
Passed all 5 tests

Thanks!
Christian
---
 fs/namespace.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 659a8f39c61a..b696543adab8 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -4263,12 +4263,11 @@ SYSCALL_DEFINE5(mount_setattr, int, dfd, const char __user *, path,
 		return err;
 
 	err = user_path_at(dfd, path, kattr.lookup_flags, &target);
-	if (err)
-		return err;
-
-	err = do_mount_setattr(&target, &kattr);
+	if (!err) {
+		err = do_mount_setattr(&target, &kattr);
+		path_put(&target);
+	}
 	finish_mount_kattr(&kattr);
-	path_put(&target);
 	return err;
 }
 

base-commit: fc74e0a40e4f9fd0468e34045b0c45bba11dcbb2
-- 
2.30.2

Re: [PATCH] fs/mount_setattr: always cleanup mount_kattr

[Linus Torvalds]

On Thu, Dec 30, 2021 at 11:23 AM Christian Brauner
<christian.brauner@ubuntu.com> wrote:
>
> Would you be ok with applying this fix directly? I

Done.

That said, I would have liked a "Fixes:" tag, or some indication of
how far back the stable people should take this..

I assume it's 9caccd41541a ("fs: introduce MOUNT_ATTR_IDMAP"), and
that's what I added manually to it as I applied it, but relying on me
noticing and getting things right can be a risky business..

              Linus

Re: [PATCH] fs/mount_setattr: always cleanup mount_kattr

[Christian Brauner]

On Thu, Dec 30, 2021 at 03:14:33PM -0800, Linus Torvalds wrote:
> On Thu, Dec 30, 2021 at 11:23 AM Christian Brauner
> <christian.brauner@ubuntu.com> wrote:
> >
> > Would you be ok with applying this fix directly? I
> 
> Done.
> 
> That said, I would have liked a "Fixes:" tag, or some indication of
> how far back the stable people should take this..

Ugh, I missed to add that.
From a pure upstream stable perspective the only relevant and still
supported kernel that should get this fix is 5.15.

I can make it a custom to mark all patches that should go to stable with
the first kernel version where a given fix should be applied. In this
case this whould've meant I'd given it:

Cc: <stable@vger.kernel.org> # v5.12+

For upstream stable maintainers it should be clear that since the only
supported stable version within the range is v5.15.
For downstream users/distros it should help to identify whether they
still run/maintain a kernel that falls within the range of kernels that
would technically be eligible for this fix.

I haven't seen whether we prefer the Cc: with # v*.**+ syntax to a
simple Cc: without it nowadays.

> 
> I assume it's 9caccd41541a ("fs: introduce MOUNT_ATTR_IDMAP"), and

Yes, that's correct. Thanks!

> that's what I added manually to it as I applied it, but relying on me
> noticing and getting things right can be a risky business..

Noted. :)

Christian

Re: [PATCH] fs/mount_setattr: always cleanup mount_kattr

[Greg KH]

On Fri, Dec 31, 2021 at 11:30:34AM +0100, Christian Brauner wrote:
> On Thu, Dec 30, 2021 at 03:14:33PM -0800, Linus Torvalds wrote:
> > On Thu, Dec 30, 2021 at 11:23 AM Christian Brauner
> > <christian.brauner@ubuntu.com> wrote:
> > >
> > > Would you be ok with applying this fix directly? I
> > 
> > Done.
> > 
> > That said, I would have liked a "Fixes:" tag, or some indication of
> > how far back the stable people should take this..
> 
> Ugh, I missed to add that.
> >From a pure upstream stable perspective the only relevant and still
> supported kernel that should get this fix is 5.15.
> 
> I can make it a custom to mark all patches that should go to stable with
> the first kernel version where a given fix should be applied. In this
> case this whould've meant I'd given it:
> 
> Cc: <stable@vger.kernel.org> # v5.12+
> 
> For upstream stable maintainers it should be clear that since the only
> supported stable version within the range is v5.15.
> For downstream users/distros it should help to identify whether they
> still run/maintain a kernel that falls within the range of kernels that
> would technically be eligible for this fix.
> 
> I haven't seen whether we prefer the Cc: with # v*.**+ syntax to a
> simple Cc: without it nowadays.

If you do the # v.** syntax, or the Fixes: tag, then I know exactly how
far back to backport things.  If a failure occurs in backporting to a
listed place, then I will send you a FAILED email.

If there is no such marking, then I just have to guess myself and if I
start to get conflicts on older kernels, I just stop and do not send a
FAILED email if it does not look obviously relevant to me.

I'll just queue this up for 5.15, thanks.

greg k-h