Re: [PATCH] firmware_loader: Fix recursive lock in device_cache_fw_images()
Aleksandr Nogikh <[email protected]>
| Newsgroups | dev.linux.lists.syzbot,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CANp29Y5=L7v0iHor=RsSURBuEv1B2oLN3pFuMkUdTXLNvo+_tA@mail.gmail.com> |
Also don't reply to any comments. Just send the patch again. On Fri, May 29, 2026 at 3:55 PM Aleksandr Nogikh <[email protected]> wrote: > > Please send the patch again. > Don't change the description or the diff; in the change list note that > the patch is resent to follow the rules. > > Now the sending mechanism will automatically set the right From: line. > > > On Thu, May 21, 2026 at 1:30 PM 'syzbot' via syzkaller-bugs > <[email protected]> wrote: > > > > 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: ac39b3ea73aa ("firmware loader: let caching firmware piggyback on loading firmware") > > Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview > > Reported-by: [email protected] > > Closes: https://syzkaller.appspot.com/bug?extid=e70e4c6f6eee43357ba7 > > Link: https://syzkaller.appspot.com/ai_job?id=8cbf9f7d-812d-4db3-89fa-0aaef3ce3a2f > > Signed-off-by: Dmitry Vyukov <[email protected]> > > > > --- > > 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); > > > > > >