Date: Sun, 10 Nov 2024 22:35:27 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 282449] UFS deadlock with install -S during freebsd-update Message-ID: <bug-282449-3630-0PjjPK4Y1F@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-282449-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-282449-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282449 --- Comment #15 from Mark Johnston <markj@FreeBSD.org> --- Looking at this again, I think the problem isn't with the general runningbufspace mechanism. There's a specific code path in the SU+J implementation where we can deadlock when hirunningspace is small. What happens is, we prepare to write a data buf, claim space for it in the runningbuf total, then call bufstrategy(), which in turn might dispatch jou= rnal I/O asynchronously, which can block on runningbufspace. Normally this happ= ens in the context of the softdep flusher, which is exempt from the runningbufs= pace limit, but it can happen in a user thread as well: _sleep+0x1f0 waitrunningbufspace+0x76 bufwrite+0x24a softdep_process_journal+0x728 softdep_disk_io_initiation+0x79b ffs_geom_strategy+0x1f0 ufs_strategy+0x83 bufstrategy+0x36 bufwrite+0x1da cluster_wbuild+0x722 cluster_write+0x12f ffs_write+0x41d When hirunningspace =3D=3D maxphys =3D=3D runningbufspace, this recursive b= ufwrite() call will block forever. I suspect this bawrite() call in softdep_process_journal() should be gated = on (curthread->td_pflags & TDP_NORUNNINGSPACE) !=3D 0. The softdep flusher wi= ll continue to issue async writes, but if a user thread is forced to flush jou= rnal records in order to initiate I/O, it'll do so synchronously. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-282449-3630-0PjjPK4Y1F>