linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAL411-pwHq4Df-FsBu=Vzd4CR6Pzee2yR579hHeZuh8T7fBNJA@mail.gmail.com>
Date:   Mon, 25 Mar 2019 16:37:09 +0800
From:   Peter Chen <hzpeterchen@...il.com>
To:     Michal Nazarewicz <mina86@...a86.com>
Cc:     Marek Szyprowski <m.szyprowski@...sung.com>,
        linux-usb@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        lkml <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
        peter.chen@....com, fugang.duan@....com
Subject: Why CMA allocater fails if there is a signal pending?

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.
Below is the call stack:

[  466.585755] [<ffff000008192f9c>] alloc_contig_range+0x1ac/0x3b8
[  466.585763] [<ffff00000820956c>] cma_alloc+0x10c/0x2d8
[  466.585772] [<ffff0000086de1bc>] dma_alloc_from_contiguous+0x3c/0x48
[  466.585779] [<ffff00000809bf20>] __dma_alloc+0xa8/0x248
[  466.585788] [<ffff0000089121e0>] xhci_mem_init+0x1c8/0x7f8
[  466.585794] [<ffff0000089074bc>] xhci_init+0x74/0x170
[  466.585800] [<ffff00000890a21c>] xhci_resume+0x184/0x630
[  466.585807] [<ffff0000088efec4>] cdns3_host_resume+0x34/0x68
[  466.585813] [<ffff0000088ebfd8>] cdns3_resume+0x1b0/0x2d0
[  466.585820] [<ffff0000086e3c10>] dpm_run_callback+0x50/0xd0
[  466.585825] [<ffff0000086e42a0>] device_resume+0xa0/0x288
[  466.585832] [<ffff0000086e5834>] dpm_resume+0xfc/0x218
[  466.585837] [<ffff0000086e5b5c>] dpm_resume_end+0x14/0x28
[  466.585844] [<ffff000008114630>] suspend_devices_and_enter+0x140/0x5b0
[  466.585849] [<ffff000008114d34>] pm_suspend+0x294/0x300
[  466.585857] [<ffff0000081136e4>] state_store+0x84/0x108
[  466.585865] [<ffff000008de9a2c>] kobj_attr_store+0x14/0x28
[  466.585873] [<ffff00000828cb90>] sysfs_kf_write+0x48/0x58
[  466.585879] [<ffff00000828be34>] kernfs_fop_write+0xcc/0x1c8
[  466.585886] [<ffff00000820e764>] __vfs_write+0x1c/0x118
[  466.585894] [<ffff00000820ea4c>] vfs_write+0xa4/0x1b0
[  466.585901] [<ffff00000820ecfc>] SyS_write+0x44/0xa0

I added WARN_ON at below code for above stack:
__alloc_contig_migrate_range
        while (pfn < end || !list_empty(&cc->migratepages)) {
                if (fatal_signal_pending(current)) {
                        WARN_ON(1);
                        ret = -EINTR;
                        break;
                }

The USB xHCI function can work well if I commented out above code.
Thanks.

BR,
Peter Chen