kern/57606: Missing lock in FFS sync code

[merlin.scholz%tu-dortmund.de@localhost]

>Number:         57606
>Category:       kern
>Synopsis:       Missing lock in FFS sync code
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 06 12:30:00 +0000 2023
>Originator:     Merlin Scholz
>Release:        10.99.5
>Organization:
TU Dortmund
>Environment:
NetBSD netbsd10 10.99.5 NetBSD 10.99.5 (GENERIC) #5: Mon Aug 21 01:01:48 CEST 2023  smmescho@mars:/home/lab/smmescho/ma/kernel/netbsd/obj/sys/arch/i386/compile/GENERIC i386
>Description:
According to the documentation provided in sys/sys/vnode.h, all vnode members, including v_numoutput, are supposed to be locked through a held v_interlock before being accessed.

This is not the case in /src/sys/ufs/ffs/ffs_vfsops.c#2024, where `ump->um_devvp->v_numoutput > 0` is being checked without prior locking of v_interlock.

The problem should be low-impact, as confirmed in #netbsd-code:
13:52 <@Riastradh> although I guess it's not actually a big issue, because either
13:53 <@Riastradh> (a) ffs_sync is being called concurrently with other file system activity, so new writes can be concurrently triggered anyway, so it doesn't really matter much; or
13:53 <@Riastradh> (b) ffs_sync is being called when the file system is quiesced, in which case it can't change anyway.

This issue has been found by performing lock analysis using LockDoc, see https://doi.org/10.1145/3302424.3303948.
>How-To-Repeat:

>Fix:
Adding the appropriate v_interlock actions in the specified code section should suffice in solving the issue. Since it is not possible to hold v_interlock across vn_lock, the if-statement would have to be split up.