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)
Fri, May 17, 8:12 PM
Unknown Object (File)
Fri, May 17, 1:51 PM
Unknown Object (File)
Sat, Apr 27, 8:39 AM
Unknown Object (File)
Sat, Apr 27, 8:39 AM
Unknown Object (File)
Sat, Apr 27, 7:20 AM
Unknown Object (File)
Apr 4 2024, 5:54 AM
Unknown Object (File)
Feb 25 2024, 1:27 PM
Unknown Object (File)
Jan 15 2024, 4:09 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.