let LLD handle bsg_job_timeout
RFC 1/1 let LLD handle bsg_job_timeout
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(-)
drivers/scsi/scsi_transport_fc.c +4 -1
@@ -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); }
James
unfortunately I posted below RFC not to you but to James B. Anyhow, it appeared on the SCSI list, have you read it by accident ?
Could you give me an idea whether the suggested change is an option ?
Thanks in advance.
Swen
Quoted 44 lines · Swen Schillig
The current
fc_bsg_job_timeoutfunction 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
===================================================================drivers/scsi/scsi_transport_fc.c +4
-2@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html