Page MenuHomeFreeBSD

add a standalone doneq for CCBs used for kernel dump I/O
AbandonedPublic

Authored by markj on Dec 19 2015, 8:59 PM.
Tags
None
Referenced Files
Unknown Object (File)
Aug 30 2025, 7:18 PM
Unknown Object (File)
Aug 21 2025, 1:09 PM
Unknown Object (File)
Aug 20 2025, 7:28 AM
Unknown Object (File)
Aug 4 2025, 9:56 AM
Unknown Object (File)
Jul 26 2025, 1:40 PM
Unknown Object (File)
Jul 13 2025, 4:28 PM
Unknown Object (File)
Jul 7 2025, 8:09 AM
Unknown Object (File)
Jul 5 2025, 4:35 PM
Subscribers

Details

Reviewers
scottl
ken
imp
mav
Summary

At the moment, adadump() and dadump() use the regular CAM completion
queues for their I/O, which can cause lockups during kernel dumps:
camisr_runqueues() may complete non-dump I/O that was pending at the
time the kernel panicked. This can result in a recursive panic if the
completion handler does something like tear down a buffer mapping or
free a CCB, and also perturbs the kernel's state after it panicked,
which is less than ideal.

This change adds a standalone queue for dump I/O. adadump() and dadump()
set a new xflag on their CCBs, and xpt_done() places CCBs with this flag
set into the dump queue. camisr_runqueues() (which is only used during
kernel dumps anyway) is modified to poll the dump queue.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 1747
Build 1753: arc lint + arc unit

Event Timeline

markj retitled this revision from to add a standalone doneq for CCBs used for kernel dump I/O.
markj edited the test plan for this revision. (Show Details)
markj updated this object.

I'm afraid that while fixing one problem this may create different one: If there were some active requests when panic happened, and some of them frozen the device, it will infinitely block the dump.

I'm revisiting this issue, but will do so with a new review.