Re: Why CMA allocater fails if there is a signal pending?

[Florian Fainelli <f.fainelli@gmail.com>]

On 3/25/19 3:26 AM, Russell King - ARM Linux admin wrote:
> On Mon, Mar 25, 2019 at 04:37:09PM +0800, Peter Chen wrote:
>> Hi Michal & Marek,
>>
>> I meet an issue that the DMA (CMA used) allocation failed if there is a user
>> signal, Eg Ctrl+C, it causes the USB xHCI stack fails to resume due to
>> dma_alloc_coherent
>> failed. It can be easy to reproduce if the user press Ctrl+C at
>> suspend/resume test.
> 
> It has been possible in the past for cma_alloc() to take seconds or
> longer to allocate, depending on the size of the CMA area and the
> number of pinned GFP_MOVABLE pages within the CMA area.  Whether that
> is true of today's CMA or not, I don't know.
> 
> It's probably there to allow such a situation to be recoverable, but
> is not a good idea if we're expecting dma_alloc_*() not to fail in
> those scenarios.
> 

This is a known issue that was discussed here before:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/299265.html

one issue is that the process that is responsible for putting the system
asleep and is being resumed (which can be as simple as your shell doing
an 'echo "standby" > /sys/power/state' can be killed, and that
propagates throughout dpm_resume(). It is debatable whether the signal
should be ignored or not, probably not.

You can work around this by wrapping your echo to /sys/power/state with
a shell script that trap the signal and say, does an exit 1. AFAIR there
are many places where a dma_alloc_* allocation can fail, and not all
drivers are designed to recover correctly.
-- 
Florian