[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <35ff02c7-8a76-730e-ddb9-f91634f5098b@tuxforce.de>
Date: Wed, 21 Apr 2021 22:42:36 +0200
From: Lukas Middendorf <kernel@...force.de>
To: Luis Chamberlain <mcgrof@...nel.org>, rafael@...nel.org,
gregkh@...uxfoundation.org, viro@...iv.linux.org.uk, jack@...e.cz,
bvanassche@....org, jeyu@...nel.org, ebiederm@...ssion.com
Cc: mchehab@...nel.org, keescook@...omium.org,
linux-fsdevel@...r.kernel.org, kexec@...ts.infradead.org,
linux-kernel@...r.kernel.org, Lukas Middendorf <kernel@...force.de>
Subject: Re: [PATCH 2/2] fs/kernel_read_file: use
usermodehelper_read_trylock() as a stop gap
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@...force.de>
> Signed-off-by: Luis Chamberlain <mcgrof@...nel.org>
Tested-by: Lukas Middendorf <kernel@...force.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
Powered by blists - more mailing lists