Re: kern/60820: LFS in-kernel cleaner can enter deadlock with build.sh

["Konrad Schroder via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60820; it has been noted by GNATS.

From: Konrad Schroder <perseant%hhhh.org@localhost>
To: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, clare%csel.org@localhost
Cc: 
Subject: Re: kern/60820: LFS in-kernel cleaner can enter deadlock with
 build.sh
Date: Fri, 23 Oct 2026 17:21:43 -0700

 On 10/6/2026 11:35 AM, Shinichi Doyashiki via gnats wrote:
 >   the cleaner thread
 >   
 >   vstate_assert_wait_stable() at netbsd:vstate_assert_wait_stable+0x4b
 >   vcache_vget() at netbsd:vcache_vget+0x34
 >   
 >   the rm process
 >   
 >   lfs_prelock() at netbsd:lfs_prelock+0x59
 >   lfs_vfree() at netbsd:lfs_vfree+0xd4
 >   lfs_reclaim() at netbsd:lfs_reclaim+0x275
 >   VOP_RECLAIM() at netbsd:VOP_RECLAIM+0x60
 >   vcache_reclaim() at netbsd:vcache_reclaim+0x1cc
 
 The essence of the deadlock is here: the cleaner, holding the segment 
 lock, has to vget the vnode to check its version number, so waits for 
 the vnode state to reach VS_RECLAIMED; while VOP_RECLAIM, waiting for 
 the segment lock, is holding that vnode in VS_RECLAIMING, so vcache_vget 
 will never return.
 
 One possibility might be simply not to check that segments are actually 
 clean before releasing them.  If all is well with LFS, we would trust 
 the accounting and would not need to check; but of course there are 
 still bugs, so this check is turned on if compiled with DEBUG.
 
 Another possibility might be to pass a flag to vcache_get() that would 
 allow it to return if the vnode state is VS_RECLAIMING (or maybe, 
 specify allowable states?), explicitly avoiding this use case.  This 
 seems a bit hackish but would avoid the deadlock.
 
 --
 Konrad Schroder
 perseant%hhhh.org@localhost