The current fc_bsg_job_timeout function offers
only two possibilities to a LLD to deal with timed out requests.
Either you deal with it offering a callback or not,
in both scenarios the environment is cleaned up afterwards.
Unfortunately we (zfcp) don't have the option
to easily abort a request. Our hardware is running its
own timer taking care of requests but unfortunately our only chance is
to wait until we receive a response. Up until then we need
the environment because the hardware might write into the provided
buffers.
The following code snippet would solve the issue for us
but maybe someone has a better idea on how to deal with the
described situation.
Cheers Swen
---
drivers/scsi/scsi_transport_fc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Index: HEAD/drivers/scsi/scsi_transport_fc.c
===================================================================
--- HEAD.orig/drivers/scsi/scsi_transport_fc.c
+++ HEAD/drivers/scsi/scsi_transport_fc.c
@@ -3500,7 +3500,10 @@ fc_bsg_job_timeout(struct request *req)
if (!done && i->f->bsg_timeout) {
/* call LLDD to abort the i/o as it has timed out */
err = i->f->bsg_timeout(job);
- if (err)
+ if (err == -EAGAIN) {
+ job->ref_cnt--;
+ return BLK_EH_RESET_TIMER;
+ } else if (err)
printk(KERN_ERR "ERROR: FC BSG request timeout - LLD "
"abort failed with status %d\n", err);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
