Re: [PATCH][next] scsi: ibmvfc: Fix spelling mistake "Deleteing" -> "Deleting"

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Uninitialized stack variable `rport` is evaluated in the NVMe target deletion loop, leading to indeterminate execution behavior and skipped target logout/deletion.
--

--- Patch [1]: [PATCH][next] scsi: ibmvfc: Fix spelling mistake "Deleteing" -> "Deleting" ---
commit 815533f3bf155a641d39add28605656b69fb9ce0
Author: Colin Ian King <[email protected]>

scsi: ibmvfc: Fix spelling mistake "Deleteing" -> "Deleting"

This commit fixes a spelling mistake in a tgt_dbg message during NVMe rport
deletion.

> diff --git a/drivers/scsi/ibmvscsi/ibmvfc-core.c b/drivers/scsi/ibmvscsi/ibmvfc-core.c
> --- a/drivers/scsi/ibmvscsi/ibmvfc-core.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc-core.c

[ ... ]

> @@ -6141,7 +6141,7 @@ static void ibmvfc_do_work(struct ibmvfc_host *vhost)
>  
>  		list_for_each_entry(tgt, &vhost->nvme_scrqs.targets, queue) {
>  			if (tgt->action == IBMVFC_TGT_ACTION_DEL_RPORT) {
> -				tgt_dbg(tgt, "Deleteing NVMe rport\n");
> +				tgt_dbg(tgt, "Deleting NVMe rport\n");
>  				nvme_rport = tgt->nvme_remote_port;
>  				list_del(&tgt->queue);
>  				ibmvfc_set_tgt_action(tgt, IBMVFC_TGT_ACTION_DELETED_RPORT);
>  				spin_unlock_irqrestore(vhost->host->host_lock, flags);
>  				if (nvme_rport)
>  					ibmvfc_nvme_unregister_remoteport(tgt);
>  				timer_delete_sync(&tgt->timer);
>  				kref_put(&tgt->kref, ibmvfc_release_tgt);
>  				return;
>  			} else if (rport && tgt->action == IBMVFC_TGT_ACTION_DEL_AND_LOGOUT_RPORT) {

[Severity: High]
This isn't a bug introduced by this patch, but is it possible that rport is
uninitialized when evaluated here?

Looking at ibmvfc_do_work(), rport is declared as a stack variable:

static void ibmvfc_do_work(struct ibmvfc_host *vhost)
{
    ...
    struct fc_rport *rport;
    ...

If no SCSI targets match the deletion criteria in the earlier loop during
IBMVFC_HOST_ACTION_TGT_DEL, rport appears to remain completely uninitialized.

When the code later reaches the NVMe loop shown above and encounters a target
with IBMVFC_TGT_ACTION_DEL_AND_LOGOUT_RPORT, it evaluates rport in the
condition.

Could this uninitialized memory evaluation cause the target deletion to be
silently skipped if it evaluates to 0, leaving the NVMe target in the
IBMVFC_TGT_ACTION_DEL_AND_LOGOUT_RPORT state forever?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1