iscsi: Mark iSCSI CAM sims as non-pollable.

[jhb]

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.

[mav]

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

[imp]

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

[mav]

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.

[imp]

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.

[jhb]

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.