Re: PR/59663 CVS commit: src/sys/dev

["J. Hannken-Illjes via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: "J. Hannken-Illjes" <hannken%mailbox.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: PR/59663 CVS commit: src/sys/dev
Date: Fri, 31 Jul 2026 17:52:31 +0200

 > On 31. Jul 2026, at 17:30, Taylor R Campbell via gnats =
 <gnats-admin%NetBSD.org@localhost> wrote:
 >=20
 > The following reply was made to PR kern/59663; it has been noted by =
 GNATS.
 >=20
 > From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
 > To: "Juergen Hannken-Illjes" <hannken%netbsd.org@localhost>
 > Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost,
 > Henryk Paluch <hpaluch%seznam.cz@localhost>
 > Subject: Re: PR/59663 CVS commit: src/sys/dev
 > Date: Fri, 31 Jul 2026 15:26:53 +0000
 >=20
 >> Module Name: src
 >> Committed By: hannken
 >> Date: Wed Jul 29 17:39:23 UTC 2026
 >>=20
 >> Modified Files:
 >> src/sys/dev: fss.c
 >>=20
 >> Log Message:
 >> Bracket I/O from or to the backing store with fstrans_start_lazy()
 >> so the fss device doesn't block before the file system is suspended.
 >>=20
 >> Should fix some deadlocks with revokation of ttys.
 >>=20
 >> PR kern/59663 (ffs_snapshot_read -> uvm_fault (or pool page empty)
 >=20
 > Do you hypothesize that this will fix the deadlocks reported in
 > https://mail-index.netbsd.org/tech-kern/2025/06/29/msg030580.html
 > and/or this PR?
 >=20
 > I'm trying to figure out how it could help, but I don't see any direct
 > connection to the fss I/O path in the stack traces in question:
 >=20
 > - In this PR, dd(1) on /dev/fssN hasn't reached it yet -- it's still
 >   waiting to busy the buffer in specfs:
 >=20
 >   cv_timedwait() at netbsd:cv_timedwait+0xd4
 >   bbusy() at netbsd:bbusy+0xe3
 >   getblk() at netbsd:getblk+0x68
 >   bio_doread() at netbsd:bio_doread+0x1d
 >   bread() at netbsd:bread+0x18
 >   spec_read() at netbsd:spec_read+0x1e6
 >   VOP_READ() at netbsd:VOP_READ+0x42
 >   vn_read() at netbsd:vn_read+0x136
 >   dofileread() at netbsd:dofileread+0x79
 >   sys_read() at netbsd:sys_read+0x49
 >   syscall() at netbsd:syscall+0x9d
 >=20
 >   I'm not sure who has the buffer busy; it's probably _not_ the
 >   process that's exiting and revoking its controlling terminal because
 >   I don't see anything in that path that could hold any buffers busy
 >   for any reason:
 >=20
 >   cv_wait_sig() at netbsd:cv_wait_sig+0xd2
 >   fstrans_setstate() at netbsd:fstrans_setstate+0x10c
 >   genfs_suspendctl() at netbsd:genfs_suspendctl+0x32
 >   VFS_SUSPENDCTL() at netbsd:VFS_SUSPENDCTL+0x25
 >   vfs_suspend() at netbsd:vfs_suspend+0x8d
 >   vrevoke_suspend_next() at netbsd:vrevoke_suspend_next+0x2a
 >   vrevoke() at netbsd:vrevoke+0x44
 >   genfs_revoke() at netbsd:genfs_revoke+0x13
 >   VOP_REVOKE() at netbsd:VOP_REVOKE+0x3b
 >   exit1() at netbsd:exit1+0x7bd
 >   sys_exit() at netbsd:sys_exit+0x3b
 >=20
 >   Having stack traces of other threads might help to find the cycle.
 >=20
 > - In https://mail-index.netbsd.org/tech-kern/2025/06/29/msg030580.html
 >   buhrow never followed up with stack traces, but csh was waiting in
 >   either open, close, or revoke (most likely revoke, I'd guess) on
 >   specfs_iocv for another thread in the middle of spec_io_enter/exit
 >   or spec_node_close.  Also not sure how that path could hold any
 >   buffers busy.
 <snip>
 
 I was able to reproduce this deadllock on my test machine and I'm sure
 the buffer is busy on the fss kthread waitiung for fss_bs_io -> vn_lock
 and here waiting for the end of the suspension of the file system:
 
 sleepq_block at sys/kern/kern_sleepq.c:392
 cv_wait at sys/kern/kern_condvar.c:182
 _fstrans_start at sys/kern/vfs_trans.c:554
 fstrans_start at sys/kern/vfs_trans.c:567
 vop_pre at sys/kern/vnode_if.c:86
 VOP_LOCK at sys/kern/vnode_if.c:1629
 vn_lock at sys/kern/vfs_vnops.c:1384
 fss_bs_io at sys/dev/fss.c:1098
 fss_bs_thread at sys/dev/fss.c:1198
 
 The recipe from Henryk works well, use old style ptys /dev/ptyXX, take a
 peristent snapshot on root fs, run dd if=3D/dev/fssX and continously
 login/logout with ssh to force the revoke of ths pty -> deadlock.
 
 --
 J. Hannken-Illjes - hannken%mailbox.org@localhost