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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 25 Mar 2019 09:44:17 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Peter Chen <hzpeterchen@...il.com>
Cc:     Michal Nazarewicz <mina86@...a86.com>, peter.chen@....com,
        fugang.duan@....com, linux-usb@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
        linux-arm-kernel@...ts.infradead.org,
        Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: Why CMA allocater fails if there is a signal pending?

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