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
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
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
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
linux-stable-mirror@lists.linaro.org
-
Christian Brauner -
Greg KH -
Linus Torvalds