Well, fc_remote_port_chkready() has in the _ONLINE and _MARGINAL case:
if (rport->roles & FC_PORT_ROLE_FCP_TARGET)
result = 0;
else if (rport->flags & FC_RPORT_DEVLOSS_PENDING)
result = DID_IMM_RETRY << 16;
else
result = DID_NO_CONNECT << 16;
break;
which fc_block_rport() does not have. Admittedly, I would have thought that
the rport would be blocked while devloss was pending but there is code in
fc_timeout_deleted_rport() that indicates otherwise, maybe this only happens
if there is a role change.
-Ewan
On Fri, May 20, 2022 at 2:50 AM Hannes Reinecke <hare@xxxxxxx> wrote:
>
> On 5/19/22 11:22, Ewan Milne wrote:
> > The patch changes the data type of the 'lun' argument to qedf_flush_active_ios()
> > to a u64, but the remaining code still uses a wildcard of -1, perhaps
> > this needs a
> > #define or enum of a value that is unsigned also?
> >
> Ah, no, I went slightly overboard there. That needs to be changed back
> to be an 'int'.
>
> > Removing the call to fc_remote_port_chkready() in qedf_initiate_tmf()
> > will result
> > in different semantics for whether the TMF will be issued.
> >
> Really? 'fc_remote_port_chkready()' just evaluates the port state;
> this is also done by fc_block_rport().
> So dropping the first shouldn't make a difference.
>
> > Changing the debug logging in qedf_eh_target_reset() and qedf_eh_device_reset()
> > might make identifying the target more difficult, although
> > qedf_initiate_tmf() will
> > also log a message, the rport->scsi_target_id is not the same value as
> > the sdev->id.
> >
> Sigh. Yes, the error logging is suboptimal.
> Will be updating it.
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke Kernel Storage Architect
> hare@xxxxxxx +49 911 74053 688
> SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
> Myers, Andrew McDonald, Martje Boudien Moerman
>
