Messages in this thread | | | Subject | Re: [PATCH 2/2] fs/kernel_read_file: use usermodehelper_read_trylock() as a stop gap | From | Lukas Middendorf <> | Date | Wed, 21 Apr 2021 22:42:36 +0200 |
| |
On 17/04/2021 01:58, Luis Chamberlain wrote: > The VFS lacks support to do automatic freeze / thaw of filesystems > on the suspend / resume cycle. This can cause some issues, namely > stalls when we have reads/writes during the suspend / resume cycle. > > Although for module loading / kexec the probability of this happening > is extremely low, maybe even impossible, its a known real issue with > the request_firmare() API which it does direct fs read. For this reason > only be chatty about the issue on the call used by the firmware API. > > Lukas Middendorf has reported an easy situation to reproduce, which can > be caused by questionably buggy drivers which call the request_firmware() > API on resume. > [snip] > > The VFS fs freeze work fixes this issue, however it requires a bit > more work, which may take a while to land upstream, and so for now > this provides a simple stop-gap solution. > > We can remove this stop-gap solution once the kernel gets VFS > fs freeze / thaw support. > > Reported-by: Lukas Middendorf <kernel@tuxforce.de> > Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Tested-by: Lukas Middendorf <kernel@tuxforce.de>
Works as advertised.
This prevents stalls on resume with buggy drivers (e.g. si2168) by totally blocking uncached request_firmware() on resume. Uncached request_firmware() will fail reliably (also in situations where it by accident worked previously without stalling). If firmware caching has been set up properly before suspend (either through firmware_request_cache() or through request_firmware() outside of a suspend/resume situation), the call to request_firmware() will still work as expected on resume. This should not break properly behaving drivers.
A failing firmware load is definitely preferable (and easier to debug and fix in the respective drivers) compared to a stall on resume.
Lukas
| |