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
F135849961: D4647.diff
Thu, Nov 13, 12:31 PM
Unknown Object (File)
Mon, Oct 27, 8:02 AM
Unknown Object (File)
Sat, Oct 25, 11:10 PM
Unknown Object (File)
Wed, Oct 22, 3:03 AM
Unknown Object (File)
Thu, Oct 16, 12:17 AM
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
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.