NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/57606: Missing lock in FFS sync code

>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
TU Dortmund
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
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

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.

Home | Main Index | Thread Index | Old Index