kern/58908: journaling log not freed when re-mounting read-only filesystem after tunefs -l 0

[cmeerw%cmeerw.org@localhost]

>Number:         58908
>Category:       kern
>Synopsis:       journaling log not freed when re-mounting read-only filesystem after tunefs -l 0
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Dec 14 21:15:00 +0000 2024
>Originator:     Christof Meerwald
>Release:        10.0
>Organization:
>Environment:
NetBSD linveo.cmeerw.net 10.0 NetBSD 10.0 (GENERIC) #0: Thu Mar 28 08:33:33 UTC 2024  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
I am trying to figure out a way to resize a root filesystem with logging enabled. As resize_ffs can't really handle a journaling log, the idea is to somehow clear the journaling log before resizing, but that's a bit tricky for the root filesystem, as that is at least always mounted read-only.

In this case I tried to use tunefs -l 0 to set the "clear journaling log" flag, and then mount with "reload" to let the kernel clear the log, but it apparently only gets as far clearing the information in the superblock, and then gives up because it's just a read-only filesystem.

With 10.0 there are no errors when trying to do this, but with HEAD you actually get some kernel messages:

[ 43102.514468] /mnt blk 128 written while ro!
[ 43102.514468] VOP_STRATEGY() at netbsd:VOP_STRATEGY+0x3c
[ 43102.514468] bwrite() at netbsd:bwrite+0x150
[ 43102.524466] ffs_sbupdate() at netbsd:ffs_sbupdate+0x219
[ 43102.524466] ffs_wapbl_start() at netbsd:ffs_wapbl_start+0x216
[ 43102.524466] ffs_mount() at netbsd:ffs_mount+0x582
[ 43102.524466] VFS_MOUNT() at netbsd:VFS_MOUNT+0x57
[ 43102.524466] do_sys_mount() at netbsd:do_sys_mount+0x435
[ 43102.524466] sys___mount50() at netbsd:sys___mount50+0x36
[ 43102.524466] syscall() at netbsd:syscall+0x112
[ 43102.524466] --- syscall (number 410) ---
[ 43102.524466] netbsd:syscall+0x112:

>How-To-Repeat:
# dd if=/dev/zero bs=1m count=64 of=x.img
64+0 records in
64+0 records out
67108864 bytes transferred in 0.075 secs (894784853 bytes/sec)
# newfs -F -O 2ea x.img 
x.img: 64.0MB (131072 sectors) block size 8192, fragment size 1024
	using 4 cylinder groups of 16.00MB, 2048 blks, 3872 inodes.
super-block backups (for fsck_ffs -b #) at:
144, 32912, 65680, 98448,
# vndconfig -c vnd0 x.img
# mount -o log /dev/vnd0 /mnt
# umount /mnt
# mount -r /dev/vnd0 /mnt
# tunefs -l 0 /dev/vnd0
tunefs: tuning /dev/rvnd0
tunefs: log file size cleared from 1048576
# mount -ruo reload /dev/vnd0 /mnt
# umount /mnt
# fsck_ffs -f /dev/vnd0
** /dev/rvnd0
** File system is already clean
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE  I=3  OWNER=0 MODE=100000
SIZE=1048576 MTIME=Dec 14 20:59 2024  
RECONNECT? [yn] y

NO lost+found DIRECTORY
CREATE? [yn] y

** Phase 5 - Check Cyl groups
ALTERNATE SUPERBLK(S) ARE INCORRECT
SALVAGE? [yn] y

FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? [yn] y

SUMMARY INFORMATION BAD
SALVAGE? [yn] y

3 files, 1034 used, 60493 free (13 frags, 7560 blocks, 0.0% fragmentation)

***** FILE SYSTEM WAS MODIFIED *****

>Fix:
At a minimum, the kernel should not leave the filesystem in an inconsistent state (so should probably just refuse to clear the journaling log pointers in the superblock for a read-only "reload" mount).