From: Mark Brown <broonie@kernel.org>
To: Eric Chanudet <echanude@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Clark Williams <clrkwllms@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>, Ian Kent <ikent@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev,
Alexander Larsson <alexl@redhat.com>,
Lucas Karpinski <lkarpins@redhat.com>,
Aishwarya.TCV@arm.com
Subject: Re: [PATCH v4] fs/namespace: defer RCU sync for MNT_DETACH umount
Date: Wed, 16 Apr 2025 23:11:51 +0100 [thread overview]
Message-ID: <fbbafa84-f86c-4ea4-8f41-e5ebb51173ed@sirena.org.uk> (raw)
In-Reply-To: <20250408210350.749901-12-echanude@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4130 bytes --]
On Tue, Apr 08, 2025 at 04:58:34PM -0400, Eric Chanudet wrote:
> Defer releasing the detached file-system when calling namespace_unlock()
> during a lazy umount to return faster.
>
> When requesting MNT_DETACH, the caller does not expect the file-system
> to be shut down upon returning from the syscall. Calling
> synchronize_rcu_expedited() has a significant cost on RT kernel that
> defaults to rcupdate.rcu_normal_after_boot=1. Queue the detached struct
> mount in a separate list and put it on a workqueue to run post RCU
> grace-period.
For the past couple of days we've been seeing failures in a bunch of LTP
filesystem related tests on various arm64 systems. The failures are
mostly (I think all) in the form:
20101 10:12:40.378045 tst_test.c:1833: TINFO: === Testing on vfat ===
20102 10:12:40.385091 tst_test.c:1170: TINFO: Formatting /dev/loop0 with vfat opts='' extra opts=''
20103 10:12:40.391032 mkfs.vfat: unable to open /dev/loop0: Device or resource busy
20104 10:12:40.395953 tst_test.c:1170: TBROK: mkfs.vfat failed with exit code 1
ie, a failure to stand up the test environment on the loopback device
all happening immediately after some other filesystem related test which
also used the loop device. A bisect points to commit a6c7a78f1b6b97
which is this, which does look rather relevant. LTP is obviously being
very much an edge case here.
Bisect log:
git bisect start
# status: waiting for both good and bad commits
# bad: [f660850bc246fef15ba78c81f686860324396628] Add linux-next specific files for 20250416
git bisect bad f660850bc246fef15ba78c81f686860324396628
# status: waiting for good commit(s), bad commit known
# good: [a6b9fbe391e8da36d2892590db4db4ff94005807] Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git
git bisect good a6b9fbe391e8da36d2892590db4db4ff94005807
# bad: [c017ce6f8d2939445ac473ada6a266aca0a0d6eb] Merge branch 'drm-next' of https://gitlab.freedesktop.org/drm/kernel.git
git bisect bad c017ce6f8d2939445ac473ada6a266aca0a0d6eb
# bad: [3efe6d22f422cbba9de75b53890c624a83dbb70a] Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
git bisect bad 3efe6d22f422cbba9de75b53890c624a83dbb70a
# good: [ce44f781015a988baf21317f7822567a62a77a5f] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git
git bisect good ce44f781015a988baf21317f7822567a62a77a5f
# good: [64a47089f778b6e4bfaaf62d4384eaa2bcaf9b63] Merge branch 'overlayfs-next' of git://git.kernel.org/pub/scm/linux/kernel/git/overlayfs/vfs.git
git bisect good 64a47089f778b6e4bfaaf62d4384eaa2bcaf9b63
# good: [cdb4a05e60b2646d25f7227c7dfe5d54c3f3a173] Merge branch 'for-next' of git://github.com/openrisc/linux.git
git bisect good cdb4a05e60b2646d25f7227c7dfe5d54c3f3a173
# good: [00b7410736b1d46ab26c3b4e04eaa819e3f7448c] Merge branch 'vfs-6.16.misc' into vfs.all
git bisect good 00b7410736b1d46ab26c3b4e04eaa819e3f7448c
# bad: [a9d6e19f91b6600c02276cd7903f747a5389950c] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git
git bisect bad a9d6e19f91b6600c02276cd7903f747a5389950c
# bad: [03e1a90f178e3cea3e8864135046e31f4dbe5e2f] Merge branch 'vfs-6.16.mount' into vfs.all
git bisect bad 03e1a90f178e3cea3e8864135046e31f4dbe5e2f
# good: [a9d7de0f68b79e5e481967fc605698915a37ac13] Merge patch series "pidfs: ensure consistent ENOENT/ESRCH reporting"
git bisect good a9d7de0f68b79e5e481967fc605698915a37ac13
# bad: [675e87c588fc7d054c8f626fd59fcad6c534f4c0] selftests/mount_settattr: add missing STATX_MNT_ID_UNIQUE define
git bisect bad 675e87c588fc7d054c8f626fd59fcad6c534f4c0
# bad: [449f3214ce15b697277d5991f096140cf773e849] selftests/mount_settattr: don't define sys_open_tree() twice
git bisect bad 449f3214ce15b697277d5991f096140cf773e849
# bad: [a6c7a78f1b6b974a10fcf4646769ba8bf2596c58] fs/namespace: defer RCU sync for MNT_DETACH umount
git bisect bad a6c7a78f1b6b974a10fcf4646769ba8bf2596c58
# first bad commit: [a6c7a78f1b6b974a10fcf4646769ba8bf2596c58] fs/namespace: defer RCU sync for MNT_DETACH umount
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2025-04-16 22:11 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 20:58 [PATCH v4] fs/namespace: defer RCU sync for MNT_DETACH umount Eric Chanudet
2025-04-09 10:37 ` Christian Brauner
2025-04-09 13:14 ` Sebastian Andrzej Siewior
2025-04-09 14:02 ` Mateusz Guzik
2025-04-09 14:25 ` Sebastian Andrzej Siewior
2025-04-09 16:04 ` Christian Brauner
2025-04-10 3:04 ` Ian Kent
2025-04-10 8:28 ` Sebastian Andrzej Siewior
2025-04-10 10:48 ` Christian Brauner
2025-04-10 13:58 ` Ian Kent
2025-04-11 2:36 ` Ian Kent
2025-04-09 16:08 ` Eric Chanudet
2025-04-11 15:17 ` Christian Brauner
2025-04-11 18:30 ` Eric Chanudet
2025-04-09 16:09 ` Christian Brauner
2025-04-10 1:17 ` Ian Kent
2025-04-09 13:04 ` Mateusz Guzik
2025-04-09 16:41 ` Eric Chanudet
2025-04-16 22:11 ` Mark Brown [this message]
2025-04-17 9:01 ` Christian Brauner
2025-04-17 10:17 ` Ian Kent
2025-04-17 11:31 ` Christian Brauner
2025-04-17 11:49 ` Mark Brown
2025-04-17 15:12 ` Christian Brauner
2025-04-17 15:28 ` Christian Brauner
2025-04-17 15:31 ` Sebastian Andrzej Siewior
2025-04-17 16:28 ` Christian Brauner
2025-04-17 22:33 ` Eric Chanudet
2025-04-18 1:13 ` Ian Kent
2025-04-18 1:20 ` Ian Kent
2025-04-18 8:47 ` Christian Brauner
2025-04-18 12:55 ` Christian Brauner
2025-04-18 19:59 ` Christian Brauner
2025-04-18 21:20 ` Eric Chanudet
2025-04-19 1:24 ` Ian Kent
2025-04-19 10:44 ` Christian Brauner
2025-04-19 13:26 ` Christian Brauner
2025-04-21 0:12 ` Ian Kent
2025-04-21 0:44 ` Al Viro
2025-04-18 0:31 ` Ian Kent
2025-04-18 8:59 ` Christian Brauner
2025-04-19 1:14 ` Ian Kent
2025-04-20 4:24 ` Al Viro
2025-04-20 5:54 ` Al Viro
2025-04-22 19:53 ` Eric Chanudet
2025-04-23 2:15 ` Al Viro
2025-04-23 15:04 ` Eric Chanudet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fbbafa84-f86c-4ea4-8f41-e5ebb51173ed@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Aishwarya.TCV@arm.com \
--cc=alexl@redhat.com \
--cc=bigeasy@linutronix.de \
--cc=brauner@kernel.org \
--cc=clrkwllms@kernel.org \
--cc=echanude@redhat.com \
--cc=ikent@redhat.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=lkarpins@redhat.com \
--cc=rostedt@goodmis.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).