All of lore.kernel.org
 help / color / mirror / Atom feed
From: "syzbot" <syzbot@kernel.org>
To: syzkaller-upstream-moderation@googlegroups.com
Cc: syzbot@lists.linux.dev
Subject: [PATCH RFC v2] firmware_loader: Fix recursive lock in device_cache_fw_images()
Date: Sat, 16 May 2026 12:26:01 +0000 (UTC)	[thread overview]
Message-ID: <83f1cd4e-d372-4be8-8ce6-32cbd7195ab1@mail.kernel.org> (raw)

A recursive locking deadlock can occur in the firmware loader's power
management notification handler.

During system suspend or hibernation preparation, fw_pm_notify() calls
device_cache_fw_images(). This function acquires fw_lock to set the
firmware cache state to FW_LOADER_START_CACHE and then iterates over
all devices using dpm_for_each_dev() while still holding the lock.

For each device, dev_cache_fw_image() schedules asynchronous work to
cache the firmware. If memory allocation for the async work entry fails
(e.g., in out-of-memory conditions), async_schedule_node_domain()
falls back to executing the work function synchronously in the current
thread.

The synchronous execution path (__async_dev_cache_fw_image() ->
cache_firmware() -> request_firmware() -> assign_fw()) attempts
to acquire fw_lock again. Since the current thread already holds
fw_lock, this results in a recursive locking deadlock.

Fix this by releasing fw_lock immediately after updating the cache
state and before calling dpm_for_each_dev(). The lock is only needed
to protect the state update. Concurrent firmware requests will correctly
see the FW_LOADER_START_CACHE state and use the piggyback mechanism,
which is independently protected by its own fwc->name_lock.

Fixes: ac39b3ea73aacde876d1d5ee1ca3e2719f771482 ("firmware loader: let caching firmware piggyback on loading firmware")
Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview
Reported-by: syzbot+e70e4c6f6eee43357ba7@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=e70e4c6f6eee43357ba7
Link: https://syzkaller.appspot.com/ai_job?id=8cbf9f7d-812d-4db3-89fa-0aaef3ce3a2f
To: <gregkh@linuxfoundation.org>
To: <linux-kernel@vger.kernel.org>
To: <rafael@kernel.org>
Cc: <dakr@kernel.org>
Cc: <driver-core@lists.linux.dev>
Cc: <mcgrof@kernel.org>
Cc: <russ.weight@linux.dev>

---
v2:
- Removed the empty comment after dpm_for_each_dev().

v1:
https://lore.kernel.org/all/7b8b3fbf-950b-4418-8cf1-772a4d639b14@mail.kernel.org/T/
---
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index a11b30dda..c96312ac2 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -1503,9 +1503,10 @@ static void device_cache_fw_images(void)
 
 	mutex_lock(&fw_lock);
 	fwc->state = FW_LOADER_START_CACHE;
-	dpm_for_each_dev(NULL, dev_cache_fw_image);
 	mutex_unlock(&fw_lock);
 
+	dpm_for_each_dev(NULL, dev_cache_fw_image);
+
 	/* wait for completion of caching firmware for all devices */
 	async_synchronize_full_domain(&fw_cache_domain);
 


base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
-- 
This is an AI-generated patch subject to moderation.
Reply with '#syz upstream' to send it to the mailing list.
Reply with '#syz reject' to reject it.

See  for more information.

                 reply	other threads:[~2026-05-16 12:26 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=83f1cd4e-d372-4be8-8ce6-32cbd7195ab1@mail.kernel.org \
    --to=syzbot@kernel.org \
    --cc=syzbot@lists.linux.dev \
    --cc=syzkaller-upstream-moderation@googlegroups.com \
    /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.