Thread (83 messages) 83 messages, 7 authors, 2022-02-23

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

From: Hannes Reinecke <hare@suse.de>
Date: 2021-08-18 11:58:37

On 8/18/21 1:00 PM, Steffen Maier wrote:
On 8/17/21 4:10 PM, Hannes Reinecke wrote:
quoted
On 8/17/21 4:03 PM, Steffen Maier wrote:
[ .. ]
quoted
quoted
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@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help