Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Runyu Xiao" <runyu.xiao@seu.edu.cn>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v2] scsi: qla2xxx: synchronize EDIF entry teardown with timer
Date: Fri, 21 Aug 2026 07:11:37 +0000	[thread overview]
Message-ID: <20260821071138.15BBB1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260821070021.92448-1-runyu.xiao@seu.edu.cn>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Uninitialized `fcport` pointer in `edif_list_entry` causes a NULL pointer dereference in the deferred freeing workqueue.
--

--- Patch [1]: [PATCH v2] scsi: qla2xxx: synchronize EDIF entry teardown with timer ---
commit 79fc4cdf869d75c3e6f24287c79efbb79add0bf0
Author: Runyu Xiao <runyu.xiao@seu.edu.cn>

scsi: qla2xxx: synchronize EDIF entry teardown with timer

This patch introduces a deferred freeing mechanism for EDIF entries to
prevent teardown races with running timer callbacks. It keeps the entry
linked while teardown is pending and queues a work item to safely free
the entry on the adapter workqueue.

Link: https://lore.kernel.org/r/20260821002708.425265-1-runyu.xiao@seu.edu.cn

> diff --git a/drivers/scsi/qla2xxx/qla_edif.c b/drivers/scsi/qla2xxx/qla_edif.c
> --- a/drivers/scsi/qla2xxx/qla_edif.c
> +++ b/drivers/scsi/qla2xxx/qla_edif.c
> @@ -163,16 +163,19 @@ static int qla_edif_list_add_sa_update_index(fc_port_t *fcport,

[ ... ]

> -	entry = kzalloc_obj(struct edif_list_entry, GFP_ATOMIC);
> -	if (!entry)
> +	new_entry = kzalloc_obj(struct edif_list_entry, GFP_ATOMIC);
> +	if (!new_entry)
>  		return -ENOMEM;
>  
> -	INIT_LIST_HEAD(&entry->next);
> -	entry->handle = handle;
> -	entry->update_sa_index = sa_index;
> -	entry->delete_sa_index = INVALID_EDIF_SA_INDEX;
> -	entry->count = 0;
> -	entry->flags = 0;
> -	timer_setup(&entry->timer, qla2x00_sa_replace_iocb_timeout, 0);
> +	INIT_LIST_HEAD(&new_entry->next);
> +	new_entry->handle = handle;
> +	new_entry->update_sa_index = sa_index;
> +	new_entry->delete_sa_index = INVALID_EDIF_SA_INDEX;
> +	new_entry->count = 0;
> +	new_entry->flags = 0;
> +	timer_setup(&new_entry->timer, qla2x00_sa_replace_iocb_timeout, 0);
> +	INIT_WORK(&new_entry->free_work, qla_edif_list_free_sa_index_work);

[Severity: High]
Does this code leave new_entry->fcport uninitialized? Looking at
qla_edif_list_add_sa_update_index(), the kzalloc_obj call zero-initializes
the memory, but there doesn't appear to be an assignment to set
new_entry->fcport to the passed-in fcport pointer.

[ ... ]

> +static void qla_edif_list_free_sa_index_work(struct work_struct *work)
> +{
> +	struct edif_list_entry *entry = container_of(work,
> +			struct edif_list_entry, free_work);
> +	fc_port_t *fcport = entry->fcport;
> +	unsigned long flags = 0;
> +	bool free_entry = false;
> +
> +	timer_shutdown_sync(&entry->timer);
> +
> +	spin_lock_irqsave(&fcport->edif.indx_list_lock, flags);

[Severity: High]
If entry->fcport is not initialized when the entry is created, will this
result in a null pointer dereference?

It looks like the worker thread in qla_edif_list_free_sa_index_work()
extracts the uninitialized fcport and attempts to acquire its spinlock,
which could lead to a crash here.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260821070021.92448-1-runyu.xiao@seu.edu.cn?part=1

      reply	other threads:[~2026-08-21  7:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21  0:27 [PATCH] scsi: qla2xxx: wait for the EDIF RX timer before freeing entries Runyu Xiao
2026-08-21  0:54 ` sashiko-bot
2026-08-21  7:00 ` [PATCH v2] scsi: qla2xxx: synchronize EDIF entry teardown with timer Runyu Xiao
2026-08-21  7:11   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260821071138.15BBB1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=runyu.xiao@seu.edu.cn \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox