zfcp FC BSG timeout fixes for 2.6.33-rc4
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 patches 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | scsi_transport_fc: Allow LLD to reset FC BSG timeoutdrivers/ | +4 | 0 replies | |
| 2/3 | zfcp: Introduce bsg_timeout callback.drivers/ drivers/ drivers/ | +8 | 0 replies | |
| 3/3 | zfcp: Set hardware timeout as requested by BSG request.drivers/ drivers/ drivers/ +1 more | +22 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [patch 0/3] zfcp FC BSG timeout fixes for 2.6.33-rc4
Here is the patch series for the FC BSG timeout problem. It is based on the initial proposal here:
http://marc.info/?l=linux-scsi&m=126043474110957&w=2
To summarize the problem and the approach taken: The block layer runs a timer for each FC BSG request. When the timer expires, the LLD's bsg_timeout function is called to abort the request. With zfcp, the hardware does not support aborting the CT or ELS request. Instead the hardware runs an internal timer that is setup from Linux for each CT and BSG request. When the request times out in the block layer, the request data structures are destroyed. When the still pending hardware request returns, it will access already freed memory.
The solution taken here is to add a special return code to the bsg_timeout callback to indicate that the block layer timer should be reset. zfcp uses this to prevent the block layer timeout. To return the FC BSG request in the time requested by the user, the hardware timer is setup with the timeout value from the FC BSG request.
The patches apply cleanly on top of 2.6.33-rc4 and the zfcp fixes posted yesterday.
--
Christof Schmitt