Re: kern/60531: looping "vflushbuf: dirty" message

I added KASSERT(VOP_ISLOCKED(vp)) to vflushbuf and to the path in
reassignbuf that puts a buffer on vp->v_dirtyblkhd, and immediately
hit:

# mount -u -o rw,noatime,nodevmtime,log /
[  20.8447068] panic: kernel diagnostic assertion "VOP_ISLOCKED(vp)" failed=
: file "/home/riastradh/netbsd/current/src/sys/kern/vfs_subr.c", line 526
[  20.8611358] cpu0: Begin traceback...
[  20.8611358] trace fp ffffc000c64ff680
[  20.8786823] fp ffffc000c64ff6b0 vpanic() at ffffc0000061f864 netbsd:vpan=
ic+0x1bc
[  20.8877138] fp ffffc000c64ff710 kern_assert() at ffffc000008c68b8 netbsd=
:kern_assert+0x58
[  20.9087004] fp ffffc000c64ff7a0 reassignbuf() at ffffc0000068639c netbsd=
:reassignbuf+0x2bc
[  20.9297182] fp ffffc000c64ff7d0 bdwrite() at ffffc000006743e8 netbsd:bdw=
rite+0x128
[  20.9507110] fp ffffc000c64ff800 ffs_nodealloccg() at ffffc00000536178 ne=
tbsd:ffs_nodealloccg+0x730
[  20.9827495] fp ffffc000c64ff8a0 ffs_hashalloc() at ffffc00000535278 netb=
sd:ffs_hashalloc+0x38
[  21.0036885] fp ffffc000c64ff900 ffs_valloc() at ffffc00000538400 netbsd:=
ffs_valloc+0xe0
[  21.0248940] fp ffffc000c64ff970 ffs_newvnode() at ffffc00000546598 netbs=
d:ffs_newvnode+0x88
[  21.0457100] fp ffffc000c64ffa00 vcache_new() at ffffc00000696738 netbsd:=
vcache_new+0x94
[  21.0667119] fp ffffc000c64ffa80 wapbl_log_position() at ffffc0000054ac3c=
 netbsd:wapbl_log_position+0x1f8
[  21.0987335] fp ffffc000c64ffca0 ffs_wapbl_start() at ffffc0000054b9b4 ne=
tbsd:ffs_wapbl_start+0x1e8
[  21.1197893] fp ffffc000c64ffd00 ffs_mount() at ffffc00000548564 netbsd:f=
fs_mount+0x564
[  21.1407173] fp ffffc000c64ffd60 do_sys_mount() at ffffc0000068a4c4 netbs=
d:do_sys_mount+0x584
[  21.1617312] fp ffffc000c64ffe10 sys___mount50() at ffffc0000068a88c netb=
sd:sys___mount50+0x28
[  21.1826953] fp ffffc000c64ffe20 syscall() at ffffc000000be2c4 netbsd:sys=
call+0x104

So I think vflushbuf's assumption that buffers are added to
v_dirtyblkhd only while the vnode lock is held may not be valid!

Now, this path involves creating a new vnode, so that may not be
relevant here.