Page MenuHomeFreeBSD

iscsi: Mark iSCSI CAM sims as non-pollable.
ClosedPublic

Authored by jhb on Mon, Feb 1, 11:32 PM.

Details

Summary

Previously, iscsi_poll() just panicked. This meant if you got a panic
on a box when using the iSCSI initiator, the attempt to shutdown would
trigger a nested panic and never write out a core. Now, CCB's sent to
iSCSI devices (such as the sychronize-cache request in dashutdown())
just fail with a timeout during a panic shutdown.

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jhb requested review of this revision.Mon, Feb 1, 11:32 PM
jhb created this revision.

Somebody will need to go through the tree and update other alike drivers, which should be plenty.

This revision is now accepted and ready to land.Mon, Feb 1, 11:44 PM

We can't get the status for the dasync stuff, but it will still be sent... Is that really a timeout error?

In D28455#636682, @imp wrote:

We can't get the status for the dasync stuff, but it will still be sent... Is that really a timeout error?

Without scheduler active request won't even be sent, since it is handled by different thread. Plus it need to allocate some memory, which is bad if we are in panic, since it may corrupt the dump.

In D28455#636684, @mav wrote:
In D28455#636682, @imp wrote:

We can't get the status for the dasync stuff, but it will still be sent... Is that really a timeout error?

Without scheduler active request won't even be sent, since it is handled by different thread. Plus it need to allocate some memory, which is bad if we are in panic, since it may corrupt the dump.

All true. Does the iscsi action routine cope? We call it higher up in the stack... other sims might be able to do something, but not get status back. Though that is largely theoretical.

In D28455#636687, @imp wrote:
In D28455#636684, @mav wrote:
In D28455#636682, @imp wrote:

We can't get the status for the dasync stuff, but it will still be sent... Is that really a timeout error?

Without scheduler active request won't even be sent, since it is handled by different thread. Plus it need to allocate some memory, which is bad if we are in panic, since it may corrupt the dump.

All true. Does the iscsi action routine cope? We call it higher up in the stack... other sims might be able to do something, but not get status back. Though that is largely theoretical.

See my comment in the other review. cam_periph_runccb() doesn't call xpt_action() for a polled request with this set of changes, so iscsi_action() will never "see" a polled ccb.

This revision was automatically updated to reflect the committed changes.