Re: [PATCH 08/51] zfcp: open-code fc_block_scsi_eh() for host reset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/18/21 1:00 PM, Steffen Maier wrote:
> On 8/17/21 4:10 PM, Hannes Reinecke wrote:
>> On 8/17/21 4:03 PM, Steffen Maier wrote:
[ .. ]
>>> It would have been nice to have a common interface for all scsi_eh
>>> scopes. I.e. fc_block_host(struct Scsi_Host*) like we already have for
>>> fc_block_scsi_eh(struct scsi_cmnd*) and fc_block_rport(struct fc_rport*)
>>> [the latter having been introduced at the time of above eh callback
>>> preparations].
>>> But if zfcp is the only one needing it for host_reset, having the code
>>> only in zfcp seems fine to me.
>>>
>>>
>> Right. Just wanted to clarify that.
>> If we need to use fc_block_rport() in host reset so be it; just wanted
>> to clarify if this _really_ is the case (and not just some copy'n'paste
>> stuff).
>> I'll be reworking the patch to call fc_block_rport().
> 
> On second thought, I might have been wrong.
> 
> The argument I used with the old commit was that we must not unblock the
> rport too early with regards to zfcp-internal recovery. This is fixed
> within zfcp recovery (erp) code. So after zfcp_erp_wait() in host_reset,
> this is still ensured; and eventually the rport unblock will occur.
> 
> I guess I was rather worried about returning from the host_reset
> callback with the async rport(s) unblock still pending. After all,
> (some) other reset_handler sync with rport unblock. However I cannot
> remember all details right now.
> 
> Before you invest more time into this, maybe just drop this patch from
> the series for now and we solve it later on? I mean it's not necessary
> for the reset_handler function signature change.
> 
Well, actually it is.
With the signature change host_reset is being called with a Scsi_Host
argument, so we cannot identify 'the' rport.
But I've modified the patch to cycle through all rports and call
fc_block_rport() on each of them.
That should be good enough for now.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@xxxxxxx			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux