From: Niklas Cassel <cassel@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: linux-ide@vger.kernel.org, dlemoal@kernel.org
Subject: Re: [PATCH] ata: libata-eh: queue hotplug work on the system_dfl_long_wq workqueue
Date: Thu, 14 May 2026 08:25:11 +0200 [thread overview]
Message-ID: <agVqx9ud0AR1NbIS@fedora> (raw)
In-Reply-To: <20260514030742.643ADC19425@smtp.kernel.org>
On Thu, May 14, 2026 at 03:07:41AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The patch fails its stated goal of unifying workqueues, leaving a Use-After-Free concurrency vulnerability intact due to broken workqueue non-reentrancy.
> --
>
> commit 30d96f652048a28eb19aca7f2ef201c2aea08917
> Author: Niklas Cassel <cassel@kernel.org>
>
> ata: libata-eh: queue hotplug work on the system_dfl_long_wq workqueue
>
> This commit changes ata_scsi_port_error_handler() to queue hotplug_task
> on system_dfl_long_wq, attempting to unify the workqueue usage with
> ata_scsi_scan_host().
>
> > ata_scsi_scan_host() queues the ap->hotplug_task work on the unbound
> > system_dfl_long_wq workqueue.
>
> Is this description of ata_scsi_scan_host() accurate?
>
> Looking at ata_scsi_scan_host(), it queues the work on system_long_wq, not
> the unbound system_dfl_long_wq.
>
> > diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
> > index 9a4b67b90b17b..6cb79a09423dd 100644
> > --- a/drivers/ata/libata-eh.c
> > +++ b/drivers/ata/libata-eh.c
> > @@ -819,7 +819,7 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, struct ata_port *ap)
> > ap->pflags &= ~ATA_PFLAG_LOADING;
> > else if ((ap->pflags & ATA_PFLAG_SCSI_HOTPLUG) &&
> > !(ap->flags & ATA_FLAG_SAS_HOST))
> > - schedule_delayed_work(&ap->hotplug_task, 0);
> > + queue_delayed_work(system_dfl_long_wq, &ap->hotplug_task, 0);
>
> Could this still leave the port vulnerable to a use-after-free regression
> during teardown?
>
> Since ata_scsi_scan_host() uses system_long_wq and this now uses
> system_dfl_long_wq, the same work can still be queued on two different
> workqueues, bypassing the workqueue non-reentrancy checks.
This patch is based on libata/for-next, where ata_scsi_scan_host() uses
system_dfl_long_wq, not system_long_wq, so the review comment by
Sashiko is incorrect.
Damien: it seems that Sashiko uses libata/HEAD by default.
I guess we could start pushing libata/for-next to libata/HEAD,
or we would need to reach out to Sashiko to make them change
the default branch that the use to apply linux-ide patches to.
Kind regards,
Niklas
next prev parent reply other threads:[~2026-05-14 6:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 8:10 [PATCH] ata: libata-eh: queue hotplug work on the system_dfl_long_wq workqueue Niklas Cassel
2026-05-14 2:13 ` Damien Le Moal
2026-05-14 3:07 ` sashiko-bot
2026-05-14 6:25 ` Niklas Cassel [this message]
2026-05-14 7:10 ` Niklas Cassel
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=agVqx9ud0AR1NbIS@fedora \
--to=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=linux-ide@vger.kernel.org \
--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.