[stgt] stgt: how to avoid WARNING at block/blk-core.c:1080

[Joe Eykholt]

On 8/5/10 4:58 PM, FUJITA Tomonori wrote:
> On Thu, 05 Aug 2010 12:28:09 -0700
> Joe Eykholt<jeykholt at cisco.com>  wrote:
>
>>> --- a/drivers/scsi/scsi_tgt_lib.c
>>> +++ b/drivers/scsi/scsi_tgt_lib.c
>>> @@ -184,6 +184,7 @@ static void scsi_tgt_cmd_destroy(struct work_struct *work)
>>>
>>>    	dprintk("cmd %p %d %u\n", cmd, cmd->sc_data_direction,
>>>    		rq_data_dir(cmd->request));
>>> +	blk_end_request_all(cmd->request, 0);
>>>    	scsi_unmap_user_pages(tcmd);
>>>    	scsi_host_put_command(scsi_tgt_cmd_to_host(cmd), cmd);
>>
>> Both blk_end_request_all() and scsi_host_put_command() do
>> a __blk_put_request().
>
> Oops, right.
>
>
>> I get a fault in the above call to scsi_tgt_cmd_to_host() where
>> it derefs the request, presumably because the request has been
>> freed by blk_end_request_all().
>>
>> This happens once, early in my LUN discovery sequence (maybe
>> an Inquiry or Report LUNs) and then it seems OK.  My system
>> goes on after the fault.

I was confused here because the fault kills the worker thread
and then scsi_tgt_cmd_destroy is not called again.  Really it
was failing the first time, and would've failed every time.

>> So, is there a case where we might not have started a request?
>
> We don't start a request (like normal requests). We just use request
> structure to keep page frames.
>
>
>> I don't see that.  I thought maybe a special case like
>> an I/O with no buffer and dir == DMA_NONE, like a Test Unit Ready.
>> Or maybe the request refcnt is not correct in some case?
>
> I'm not sure. I think that only blk_execute_rq plays with
> req->ref_count.
>
>
>> I tried merely getting the host pointer before blk_end_request_all(),
>> but that just lead to another problem in scsi_host_put_command()
>> since it also refers to the request to get the tcmd.
>
> I think that just setting req->bio to NULL is the simplest solution.

Thanks, that works better.  Thanks a bunch!
I'll send my next issue in a little bit.  I think it's easier.

	Regards,
	Joe


--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html