netdev - Re: DMA allocations from CMA and fatal_signal

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141031082818.GB14642@js1304-P5Q-DELUXE>
Date:	Fri, 31 Oct 2014 17:28:18 +0900
From:	Joonsoo Kim <iamjoonsoo.kim@....com>
To:	Florian Fainelli <f.fainelli@...il.com>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Brian Norris <computersforpeace@...il.com>,
	Gregory Fong <gregory.0xf0@...il.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	lauraa@...eaurora.org, gioh.kim@....com,
	aneesh.kumar@...ux.vnet.ibm.com, mina86@...a86.com,
	m.szyprowski@...sung.com, akpm@...ux-foundation.org,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: DMA allocations from CMA and fatal_signal_pending check

On Tue, Oct 28, 2014 at 12:08:46PM -0700, Florian Fainelli wrote:
> Hello,
> 
> While debugging why some dma_alloc_coherent() allocations where
> returning NULL on our brcmstb platform, specifically with
> drivers/net/ethernet/broadcom/bcmcsysport.c, I came across the
> fatal_signal_pending() check in mm/page_alloc.c which is there.
> 
> This driver calls dma_alloc_coherent(, GFP_KERNEL) which ends up making
> a coherent allocation from a CMA region on our platform. Since that
> allocation is allowed to sleep, and because we are in bcm_syport_open(),
> executed from process context, a pending signal makes
> dma_alloc_coherent() return NULL.

Hello, Florian.

fatal_signal_pending means that there is SIGKILL on that process.
I guess that caller of dma_alloc_coherent() will die soon.
In this case, why CMA should be succeed?

> 
> There are two ways I could fix this:
> 
> - use a GFP_ATOMIC allocation, which would avoid this sensitivity to a
> pending signal being fatal (we suffer from the same issue in
> bcm_sysport_resume)
> 
> - move the DMA coherent allocation before bcm_sysport_open(), in the
> driver's probe function, but if the network interface is never used, we
> would be waisting precious DMA coherent memory for nothing (it is only 4
> bytes times 32 but still

I guess that it is okay that bcm_sysport_open() return -EINTR?

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html