[Bug 261387] Should cam be calling callout drain for struct cam_sim and struct cam_ed?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261387

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=28027f28e607012b83ee9062eed3b8ed82e819c1

I think you're right that it should have been drained, but it's somewhat moot
since it apparently wasn't used.

The cam_ed callout is a bit more complicated: it's interlocked by the device'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 callout,
and xpt_release_devq_timeout() presumably won't access a "doomed" device after
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.