Bug 273953 - panic: vfs_remount_ro: mp is not busied
Summary: panic: vfs_remount_ro: mp is not busied
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 15.0-CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Konstantin Belousov
URL:
Keywords: crash
Depends on:
Blocks:
 
Reported: 2023-09-20 01:22 UTC by Gleb Smirnoff
Modified: 2023-10-02 12:40 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gleb Smirnoff freebsd_committer freebsd_triage 2023-09-20 01:22:28 UTC
With msdosfs(4) on an SD card mounted with help of autofs(5) paniced when running command 'rm *' in directory that had 3 files. Repeating same scenario on the same file system after reboot did not reproduce the panic, so seems to be a race.

I got core.

Unread portion of the kernel message buffer:
/stealth: Freeing unused sector 158705 17 0
/dev/msdosfs/STEALTHCAM: remounting read-only due to corruption
panic: vfs_remount_ro: mp 0xfffffe0235211000 is not busied
cpuid = 19
time = 1695171728
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame 0xfffffe015d040b30
kdb_backtrace() at kdb_backtrace+0x46/frame 0xfffffe015d040be0
vpanic() at vpanic+0x20f/frame 0xfffffe015d040d20
panic() at panic+0x4e/frame 0xfffffe015d040d80
vfs_remount_ro() at vfs_remount_ro+0x3f/frame 0xfffffe015d040e00
msdosfs_remount_ro() at msdosfs_remount_ro+0x170/frame 0xfffffe015d040e40
taskqueue_run_locked() at taskqueue_run_locked+0x2a2/frame 0xfffffe015d040eb0
taskqueue_thread_loop() at taskqueue_thread_loop+0xad/frame 0xfffffe015d040ee0
fork_exit() at fork_exit+0x10a/frame 0xfffffe015d040f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe015d040f30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 11d17h24m24s
Dumping 19323 out of 65306 MB: (CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to abort) ..1% (CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to abort) ..11%..21%..31%..41%..51%..61%..71%..81%..91%

0xffffffff80c4934b in doadump (textdump=1) at /usr/src/FreeBSD/sys/kern/kern_shutdown.c:405
405             dump_savectx();
(kgdb) bt
#0  0xffffffff80c4934b in doadump (textdump=1) at /usr/src/FreeBSD/sys/kern/kern_shutdown.c:405
#1  0xffffffff80c48f9b in kern_reboot (howto=260) at /usr/src/FreeBSD/sys/kern/kern_shutdown.c:526
#2  0xffffffff80c49ab2 in vpanic (fmt=0xffffffff8119d417 "vfs_remount_ro: mp %p is not busied", ap=0xfffffe015d040d60)
    at /usr/src/FreeBSD/sys/kern/kern_shutdown.c:970
#3  0xffffffff80c492ee in panic (fmt=0xffffffff8119d417 "vfs_remount_ro: mp %p is not busied") at /usr/src/FreeBSD/sys/kern/kern_shutdown.c:894
#4  0xffffffff80d8df3f in vfs_remount_ro (mp=0xfffffe0235211000) at /usr/src/FreeBSD/sys/kern/vfs_mount.c:3007
#5  0xffffffff80a87b80 in msdosfs_remount_ro (arg=0xfffff803c9e4c200, pending=1) at /usr/src/FreeBSD/sys/fs/msdosfs/msdosfs_vfsops.c:996
#6  0xffffffff80cdc392 in taskqueue_run_locked (queue=0xfffff80001d46900) at /usr/src/FreeBSD/sys/kern/subr_taskqueue.c:512
#7  0xffffffff80cdd74d in taskqueue_thread_loop (arg=0xffffffff817d8998 <taskqueue_thread>) at /usr/src/FreeBSD/sys/kern/subr_taskqueue.c:824
#8  0xffffffff80be4d4a in fork_exit (callout=0xffffffff80cdd6a0 <taskqueue_thread_loop>, arg=0xffffffff817d8998 <taskqueue_thread>, 
    frame=0xfffffe015d040f40) at /usr/src/FreeBSD/sys/kern/kern_fork.c:1160
#9  <signal handler called>
(kgdb) frame 4
#4  0xffffffff80d8df3f in vfs_remount_ro (mp=0xfffffe0235211000) at /usr/src/FreeBSD/sys/kern/vfs_mount.c:3007
3007            KASSERT(mp->mnt_lockref > 0,
(kgdb) p *mp
$1 = {mnt_vfs_ops = 0, mnt_kern_flag = 16640, mnt_flag = 8589938688, mnt_pcpu = 0xfffffe02a939de50, mnt_rootvnode = 0x0, 
  mnt_vnodecovered = 0xfffff8048f8f3e00, mnt_op = 0xffffffff8147d938 <msdosfs_vfsops>, mnt_vfc = 0xffffffff8147d8e8 <msdosfs_vfsconf>, mnt_mtx = {
    lock_object = {lo_name = 0xffffffff8115e318 "struct mount mtx", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}, 
  mnt_gen = 2, mnt_list = {tqe_next = 0x0, tqe_prev = 0xfffffe0235211b68}, mnt_syncer = 0xfffff80496430540, mnt_ref = 9, mnt_nvnodelist = {
    tqh_first = 0xfffff80496430540, tqh_last = 0xfffff8048ee0d568}, mnt_nvnodelistsize = 7, mnt_writeopcount = 1, mnt_opt = 0xfffff8070e1edc10, 
  mnt_optnew = 0x0, mnt_stat = {f_version = 538182936, f_type = 50, f_flags = 8589938688, f_bsize = 32768, f_iosize = 32768, f_blocks = 485944, 
    f_bfree = 308820, f_bavail = 308820, f_files = 0, f_ffree = 0, f_syncwrites = 9, f_asyncwrites = 2, f_syncreads = 510, f_asyncreads = 313, 
    f_nvnodelistsize = 9, f_spare0 = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {345, 50}}, 
    f_charspare = '\000' <repeats 79 times>, f_fstypename = "msdosfs\000\000\000\000\000\000\000\000", 
    f_mntfromname = "/dev/msdosfs/STEALTHCAM", '\000' <repeats 1000 times>, f_mntonname = "/stealth", '\000' <repeats 1015 times>}, 
  mnt_cred = 0xfffff80391380000, mnt_data = 0xfffff803c9e4c200, mnt_time = 0, mnt_iosize_max = 1048576, mnt_export = 0x0, mnt_label = 0x0, 
  mnt_hashseed = 3245099513, mnt_lockref = 0, mnt_secondary_writes = 0, mnt_secondary_accwrites = 0, mnt_susp_owner = 0x0, mnt_exjail = 0x0, 
  mnt_gjprovider = 0x0, mnt_listmtx = {lock_object = {lo_name = 0xffffffff811d2344 "struct mount vlist mtx", lo_flags = 16973824, lo_data = 0, 
      lo_witness = 0x0}, mtx_lock = 0}, mnt_lazyvnodelist = {tqh_first = 0x0, tqh_last = 0xfffffe0235211a50}, mnt_lazyvnodelistsize = 0, 
  mnt_upper_pending = 0, mnt_explock = {lock_object = {lo_name = 0xffffffff8123df49 "explock", lo_flags = 108199936, lo_data = 0, 
      lo_witness = 0x0}, lk_lock = 1, lk_exslpfail = 0, lk_pri = 64, lk_timo = 0}, mnt_uppers = {tqh_first = 0x0, tqh_last = 0xfffffe0235211a90}, 
  mnt_notify = {tqh_first = 0x0, tqh_last = 0xfffffe0235211aa0}, mnt_taskqueue_link = {stqe_next = 0x0}, mnt_taskqueue_flags = 0, 
  mnt_unmount_retries = 0}
Comment 1 Konstantin Belousov freebsd_committer freebsd_triage 2023-09-20 03:45:31 UTC
This is cosmetic issue.
mnt_lockref should be asserted only after vfs_op_enter().
Patch below should be enough.

commit 5a85fa192ec81998b723361028da21c5bcb4e66f
Author: Konstantin Belousov <kib@FreeBSD.org>
Date:   Wed Sep 20 06:42:31 2023 +0300

    vfs_remount_ro(): mnt_lockref should be only accessed after vfs_op_enter()
    
    PR:     273953

diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c
index 45ab9cfc93cc..8364081585f8 100644
--- a/sys/kern/vfs_mount.c
+++ b/sys/kern/vfs_mount.c
@@ -3004,6 +3004,7 @@ vfs_remount_ro(struct mount *mp)
 	struct vnode *vp_covered, *rootvp;
 	int error;
 
+	vfs_op_enter(mp);
 	KASSERT(mp->mnt_lockref > 0,
 	    ("vfs_remount_ro: mp %p is not busied", mp));
 	KASSERT((mp->mnt_kern_flag & MNTK_UNMOUNT) == 0,
@@ -3012,17 +3013,19 @@ vfs_remount_ro(struct mount *mp)
 	rootvp = NULL;
 	vp_covered = mp->mnt_vnodecovered;
 	error = vget(vp_covered, LK_EXCLUSIVE | LK_NOWAIT);
-	if (error != 0)
+	if (error != 0) {
+		vfs_op_exit(mp);
 		return (error);
+	}
 	VI_LOCK(vp_covered);
 	if ((vp_covered->v_iflag & VI_MOUNT) != 0) {
 		VI_UNLOCK(vp_covered);
 		vput(vp_covered);
+		vfs_op_exit(mp);
 		return (EBUSY);
 	}
 	vp_covered->v_iflag |= VI_MOUNT;
 	VI_UNLOCK(vp_covered);
-	vfs_op_enter(mp);
 	vn_seqc_write_begin(vp_covered);
 
 	MNT_ILOCK(mp);
Comment 2 Gleb Smirnoff freebsd_committer freebsd_triage 2023-09-20 05:14:51 UTC
Thanks, Konstantin! I can't test it since don't have reproducer.
Comment 3 commit-hook freebsd_committer freebsd_triage 2023-09-21 01:00:02 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=c584bb9cac16bc200ac45cc8b709e7e7e99e24bb

commit c584bb9cac16bc200ac45cc8b709e7e7e99e24bb
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: 2023-09-20 03:42:31 +0000
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2023-09-21 00:59:11 +0000

    vfs_remount_ro(): mnt_lockref should be only accessed after vfs_op_enter()

    PR:     273953
    Sponsored by:   The FreeBSD Foundation
    MFC after:      1 week

 sys/kern/vfs_mount.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
Comment 4 commit-hook freebsd_committer freebsd_triage 2023-09-28 09:06:17 UTC
A commit in branch stable/14 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=5b200ff58126a028ba357f297cbb596a7475962c

commit 5b200ff58126a028ba357f297cbb596a7475962c
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: 2023-09-20 03:42:31 +0000
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2023-09-28 09:05:05 +0000

    vfs_remount_ro(): mnt_lockref should be only accessed after vfs_op_enter()

    PR:     273953

    (cherry picked from commit c584bb9cac16bc200ac45cc8b709e7e7e99e24bb)

 sys/kern/vfs_mount.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
Comment 5 commit-hook freebsd_committer freebsd_triage 2023-09-28 09:07:19 UTC
A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=40cec659c167d1773826cf44f5ef6394cb0ad8fd

commit 40cec659c167d1773826cf44f5ef6394cb0ad8fd
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: 2023-09-20 03:42:31 +0000
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2023-09-28 09:06:23 +0000

    vfs_remount_ro(): mnt_lockref should be only accessed after vfs_op_enter()

    PR:     273953

    (cherry picked from commit c584bb9cac16bc200ac45cc8b709e7e7e99e24bb)

 sys/kern/vfs_mount.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
Comment 6 Mark Johnston freebsd_committer freebsd_triage 2023-10-02 12:40:40 UTC
I'll presume that the bug is fixed now.