Date: Tue, 25 Jan 2022 15:38:06 +0000 From: bugzilla-noreply@freebsd.org To: scsi@FreeBSD.org Subject: [Bug 261387] Should cam be calling callout drain for struct cam_sim and struct cam_ed? Message-ID: <bug-261387-5313-8KRnYFLXmX@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-261387-5313@https.bugs.freebsd.org/bugzilla/> References: <bug-261387-5313@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=3D261387 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open CC| |markj@FreeBSD.org Assignee|bugs@FreeBSD.org |scsi@FreeBSD.org --- Comment #1 from Mark Johnston <markj@FreeBSD.org> --- Looks like the cam_sim callout has been removed: https://cgit.freebsd.org/src/commit/?id=3D28027f28e607012b83ee9062eed3b8ed8= 2e819c1 I think you're right that it should have been drained, but it's somewhat mo= ot since it apparently wasn't used. The cam_ed callout is a bit more complicated: it's interlocked by the devic= e's SIM's devq lock, dev->sim->devq->send_mtx. So the callout handler, xpt_release_devq_timeout(), runs with send_mtx held, as does xpt_release_device() when it stops the callout. The interlock is mostly sufficient to ensure that the callout does not continue running. It's not completely sufficient, though, since xpt_release_devq_timeout() may drop the send_mtx lock to schedule I/O (presumably from a different device). During this window, xpt_release_device() may try to stop the callout, fail, and continue destroying the device, while the callout is still running. It's not very clear whether it's ok to free a callout while the handler is running. At that point the callout subsystem no longer references the call= out, and xpt_release_devq_timeout() presumably won't access a "doomed" device af= ter dropping the send lock, since it's shouldn't appear in the devq anymore. So I suspect that it's mostly a theoretical problem, though the callout documentation really doesn't make this clear. --=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-261387-5313-8KRnYFLXmX>