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
prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.