Re: [PATCH 1/2] scsi_transport_fc: FC pass through support via bsg interface - revised

FUJITA Tomonori
2008-10-24T03:55:43Z

CC'ed Jens,

On Wed, 22 Oct 2008 19:27:35 -0700
Seokmann Ju <seokmann.ju@qlogic.com> wrote:

> And it seems like that the panic is happening due to the fact that
> blk_delete_timer() is not called upon having completion of the service.
> In other words, the block layer calls blk_add_timer() prior to
> dispatch the service but, it doesn't call blk_delete_timer() when it
> returned.

Yeah, we need to call blk_delete_timer somewhere.

> Just for heck of it, I've tried out by adding blk_delete_timer() in
> the ~/block/blk-exec.c:blk_end_sync_rq() and it seems fixes the problem.

I think blk_end_sync_rq() is not the good place. From the perspective
of bsg, we need to handle both blk_execute_rq_nowait and
blk_execute_rq.

> Seems like that there are APIs in the block layer that are call the
> blk_delete_timer(), including,
> - blk_end_io()
> - __blk_end_request()
>
> Could you guide me what is right way to fix the problem?

Exporting blk_delete_timer is one option, but it doesn't look very
nice (since the block layer doesn't export any details about its timer
infrastructure), I think. Modifying blk_end_io() to make it usable for
requests via something like bsg might be better.

Anyway, we need to ask Jens.

Jens, fc people have working on fc pass through support via bsg, which
hooks bsg's request queue on fc transport objects (We did the similar
thing for sas transport).

We want the timeout feature for fc pass through and I think that it's
nice to use the block layer timeout feature for it. But the users of
bsg request queue don't need (or call) APIs such as
end_that_request_last to call blk_delete_timer internally. How should
these users call blk_delete_timer?