Re: [PATCH]qla4xxx:Add support for Async Message PDUs [REPOST with fixes]

[Mike Christie <michaelc@cs.wisc.edu>]

David C Somayajulu wrote:
> On Wed, 2008-04-30 at 14:36 -0500, Mike Christie wrote:
>> Mike Christie wrote:
>>> David C Somayajulu wrote:
>>>> +        }
>>>> +        if (sshdr.asc == 0x3f && sshdr.ascq == 0x0e) {
>>>> +            /* induce rescan */
>>>> +            iscsi_block_session(ddb_entry->sess);
>>>> +            iscsi_unblock_session(ddb_entry->sess);
>>>> +        }
>>> I think I was wrong off list. We could actually just call 
>>> iscsi_unblock_session, but we do not know the state of the session do 
>>> we? If we got a event that indicated the session was failed could we 
>>> have a block queued up and this would reverse it by accident?
>>>
>>> I was thinking that because qla4xxx_process_aen is called before this we 
>>> could just check the ddb state, but we can call iscsi_block_session from 
>>> the interrupt handler to queue up a block so I think that could race 
>>> with the unblock call here.
>> Maybe to handle the race we do not want to call qla4xxx_mark_device_busy 
>> when we get SCS_TIMEOUT. If we get a ddb aen then could we just wait for 
>> that and all those events would be serialized through the dpc thread?
>>
>> What does SCS_TIMEOUT mean?
> I think the driver on receiving the Async Message PDU of type
> ISCSI_ASYNC_MSG_SCSI_EVENT, should first retrieve the DDB state. If the
> session is still not active, it should block it. If the DDB state

You should not need to block it though. qla4xxx_process_aen will have 
done this already when it set the ddb state, wouldn't it? I am saying if 
the ddb state indicates that it is not active then the session should be 
in the blocked state by the time we get to handling the iscsi async event.


> indicates the session is active, then call iscsi_unblock_session() if
> rescan is needed. What do you think of this solution ?
> 
> SCS_TIMEOUT is generated when there is a transport layer timeout for one
> of the PDUs issued as result of an IOCB.
> 

Do you need some locking or something then? If the dpc thread is about 
to check the ddb state to handle the iscsi async pdu like we said above, 
then we get a SCS_TIMEOUT, could the dpc thread read the ddb state and 
see a good ddb state, then the SCS_TIMEOUT handling would set the state 
to DDB_STATE_MISSING and queue a block. The dpc thread would then queue 
a unblock early?