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

From: Florian Fainelli
Date: Mon Mar 25 2019 - 12:44:33 EST

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:

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.