summaryrefslogtreecommitdiff
path: root/fs/kernfs
diff options
context:
space:
mode:
authorMukesh Ojha <quic_mojha@quicinc.com>2023-10-26 19:57:39 +0530
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2023-10-27 13:30:38 +0200
commiteffd7c70eaa0440688b60b9d419243695ede3c45 (patch)
tree5f0442ebf680b9d381e7912a8f49a2d1ef23cafe /fs/kernfs
parent87ffa98eeee8d62a56afdad80ea697e7a6e5c354 (diff)
firmware_loader: Abort all upcoming firmware load request once reboot triggered
There could be following scenario where there is a ongoing reboot is going from processA which tries to call all the reboot notifier callback and one of them is firmware reboot call which tries to abort all the ongoing firmware userspace request under fw_lock but there could be another processB which tries to do request firmware, which came just after abort done from ProcessA and ask for userspace to load the firmware and this can stop the ongoing reboot ProcessA to stall for next 60s(default timeout) which may not be expected behaviour everyone like to see, instead we should abort any firmware load request which came once firmware knows about the reboot through notification. ProcessA ProcessB kernel_restart_prepare blocking_notifier_call_chain fw_shutdown_notify kill_pending_fw_fallback_reqs __fw_load_abort fw_state_aborted request_firmware __fw_state_set firmware_fallback_sysfs ... fw_load_from_user_helper .. ... . .. usermodehelper_read_trylock fw_load_sysfs_fallback fw_sysfs_wait_timeout usermodehelper_disable __usermodehelper_disable down_write() Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Link: https://lore.kernel.org/r/1698330459-31776-2-git-send-email-quic_mojha@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'fs/kernfs')
0 files changed, 0 insertions, 0 deletions