kern/60531: looping "vflushbuf: dirty" message

["campbell+netbsd%mumble.net@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60531
>Category:       kern
>Synopsis:       looping "vflushbuf: dirty" message
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Aug 02 14:40:00 +0000 2026
>Originator:     Taylor R Campbell
>Release:        10.1
>Organization:
The NetBSD Foundation, Inc.
>Environment:
NetBSD franklin.NetBSD.org 10.1_STABLE NetBSD 10.1_STABLE (FRANKLIN) #0: Tue Jan 28 19:43:34 UTC 2025  spz%franklin.NetBSD.org@localhost:/home/netbsd/10/amd64/obj/sys/arch/amd64/compile/FRANKLIN amd64
>Description:

	Sometimes, under heavy load (possibly snapshot-related), the
	kernel starts to spew this to the console:

vflushbuf: dirty: vnode 0xffffea44c2bd54c0 flags 0x4010<MPSAFE,ONWORKLST>
    tag VT_UFS(1) type VBLK(3) mount 0xffffea4ab61a2000 typedata 0xffffea4ab5f92560
    usecount 123652 writecount 0 holdcount 6035
    size 0 writesize 0 numoutput 0
    data 0xffffea44c2602558 lock 0xffffea44c2bd5680
    state LOADED key(0xffffea4ab61a2000 8) dd 23 23 00 00 00 00 00
    lrulisthd 0xffffffff80e88390
    tag VT_UFS, ino 2302941, on dev 4, 0 flags 0x0, nlink 1
    mode 060640, owner 0, group 5, size 0

	or

vflushbuf: dirty: vnode 0xffffcca82a4784c0 flags 0x4010<MPSAFE,ONWORKLST>
        tag VT_UFS(1) type VBLK(3) mount 0xffffcca82c32b000 typedata 0xffffcca82c13cf00
        usecount 30 writecount 0 holdcount 32
        size 0 writesize 0 numoutput 0
        data 0xffffcca82ab9a668 lock 0xffffcca82a478680
        state LOADED key(0xffffcca82c32b000 8) dd 23 23 00 00 00 00 00
        lrulisthd 0xffffffff80e88390
        tag VT_UFS, ino 2302941, on dev 4, 0 flags 0x0, nlink 1
        mode 060640, owner 0, group 5, size 0

	An incomprehensibly terse message like this is scary and bad
	enough for warning fatigue even if it is otherwise harmless,
	but it also sometimes renders the machine unusable by spewing
	constantly to the console.

	The inode and mounts in question here are:

$ ls -li /dev/sd0a /dev/dk0
2302941 brw-r-----  1 root  operator  168, 0 Oct 31  2015 /dev/dk0
2301566 brw-r-----  1 root  operator    4, 0 Oct 31  2015 /dev/sd0a
$ mount | grep -e dk0 -e sd0a
/dev/sd0a on / type ffs (log, noatime, nodevmtime, local)
/dev/dk0 on /storage type ffs (local)

	The messages have manifested on different machines over time,
	but these are the only ones I have handy to review.  From the
	sample I have, and from discussion with hannken@, I suspect
	it's always VBLK devices.

	When this last happened, there was an active snapshot of /
	being dumped, and heavy I/O to /storage to write dumps from
	this host and from various other hosts.

	There's a comment atop vflushbuf saying it assumes that holding
	the vnode lock (which it doesn't assert!) guarantees that new
	dirty buffers won't be queued, but I suspect there may be a
	path to queueing new dirty buffers _for VBLK vnodes_:

    330 /*
    331  * Flush all dirty buffers from a vnode.
    332  * Called with the underlying vnode locked, which should prevent new dirty
    333  * buffers from being queued.
    334  */
    335 int
    336 vflushbuf(struct vnode *vp, int flags)
    337 {
...
    349 loop:
    350 	mutex_enter(&bufcache_lock);
    351 	for (bp = LIST_FIRST(&vp->v_dirtyblkhd); bp; bp = nbp) {
    352 		KASSERT(bp->b_vp == vp);
...
    372 	}
    373 	mutex_exit(&bufcache_lock);
    374 
    375 	if (!sync)
    376 		return 0;
    377 
    378 	mutex_enter(vp->v_interlock);
    379 	while (vp->v_numoutput != 0)
    380 		cv_wait(&vp->v_cv, vp->v_interlock);
    381 	dirty = !LIST_EMPTY(&vp->v_dirtyblkhd);
    382 	mutex_exit(vp->v_interlock);
    383 
    384 	if (dirty) {
    385 		vprint("vflushbuf: dirty", vp);
    386 		goto loop;
    387 	}

>How-To-Repeat:

	not sure, maybe just heavy I/O and running sync(8)

>Fix:

	Yes, please!

	Possible workaround: print the message only if the vnode type
	is not VBLK.