From: "Danilo Krummrich" <dakr@kernel.org>
To: "Cássio Gabriel" <cassiogabrielcontato@gmail.com>
Cc: "Luis Chamberlain" <mcgrof@kernel.org>,
"Russ Weight" <russ.weight@linux.dev>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Takashi Iwai" <tiwai@suse.com>,
"Shenghao Ding" <shenghao-ding@ti.com>,
"Kevin Lu" <kevin-lu@ti.com>, "Baojun Xu" <baojun.xu@ti.com>,
"Jaroslav Kysela" <perex@perex.cz>, <driver-core@lists.linux.dev>,
<linux-kernel@vger.kernel.org>, <linux-sound@vger.kernel.org>,
"Takashi Iwai" <tiwai@suse.de>
Subject: Re: [PATCH v2 1/2] firmware_loader: Add cancel helper for async requests
Date: Fri, 01 May 2026 00:44:42 +0200 [thread overview]
Message-ID: <DI6UQN8M515K.3KSH2M0AXDTRG@kernel.org> (raw)
In-Reply-To: <20260430-alsa-hda-tas2781-fw-callback-teardown-v2-1-2c7d89cb3175@gmail.com>
On Thu Apr 30, 2026 at 11:15 PM CEST, Cássio Gabriel wrote:
> request_firmware_nowait() keeps the callback module pinned and holds
> a device reference until the firmware work completes.
>
> Callers still have no way to cancel or synchronize the queued callback
> before tearing down their driver-private state.
>
> Track async firmware work with devres and add
> request_firmware_nowait_cancel().
I assume this is needed for manual ordering in case the callback accesses
resources that are not managed by devres, but are released in remove().
So, I think this is mixing two patterns, managed by the caller and devres
managed.
For the former we just want the ability to cancel things, this should be
compatible with the existing request_firmware_nowait().
Note that some (hopefully most) drivers already open code synchronization
patterns, e.g. a completion that is waited for in remove().
However, some drivers also seem to just check a pointer, which is obviously
vulnerable to TOCTOU races.
For a devres managed version, I think it should be a new API,
devm_request_firmware_nowait(), which should be possible to simply layer on top
of the existing API with devm_add_action(), so you can just call cancel() from
the release callback.
> The helper cancels work that has not
> started yet and waits for an already-running callback to return. If the
> request has already completed, it is a no-op.
>
> The devres release path uses the same synchronization so device teardown
> cannot free the firmware work state while the queued work can still run.
>
> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
<snip>
> @@ -1184,18 +1213,19 @@ static int _request_firmware_nowait(
>
> if (!uevent && fw_cache_is_setup(device, name)) {
> kfree_const(fw_work->name);
> - kfree(fw_work);
> + devres_free(fw_work);
> return -EOPNOTSUPP;
> }
>
> if (!try_module_get(module)) {
> kfree_const(fw_work->name);
> - kfree(fw_work);
> + devres_free(fw_work);
> return -EFAULT;
> }
>
> get_device(fw_work->device);
> INIT_WORK(&fw_work->work, request_firmware_work_func);
> + devres_add(device, fw_work);
This puts the requirement on request_firmware_nowait() that it must be called
from a context where the device is guaranteed to not be unbound concurrently,
otherwise this may race with firmware_work_release(), which could free fw_work
before this functions attempts to schedule it below.
As mentioned above, I think this patch should just add a cancel() function, so
we can layer devres managed functionality on top of that as needed.
next prev parent reply other threads:[~2026-04-30 22:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 21:15 [PATCH v2 0/2] firmware_loader/ALSA: Fix TAS2781 async firmware teardown Cássio Gabriel
2026-04-30 21:15 ` [PATCH v2 1/2] firmware_loader: Add cancel helper for async requests Cássio Gabriel
2026-04-30 22:44 ` Danilo Krummrich [this message]
2026-05-01 3:28 ` Cássio Gabriel Monteiro Pires
2026-04-30 21:15 ` [PATCH v2 2/2] ALSA: hda/tas2781: Cancel async firmware request at unbind Cássio Gabriel
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=DI6UQN8M515K.3KSH2M0AXDTRG@kernel.org \
--to=dakr@kernel.org \
--cc=baojun.xu@ti.com \
--cc=cassiogabrielcontato@gmail.com \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=kevin-lu@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=perex@perex.cz \
--cc=rafael@kernel.org \
--cc=russ.weight@linux.dev \
--cc=shenghao-ding@ti.com \
--cc=tiwai@suse.com \
--cc=tiwai@suse.de \
/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