linux-kernel - Re: [BUG] XHCI getting ZONE_DMA32 memory > than its bus_dma

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]

Date:   Fri, 03 Jul 2020 16:53:45 +0200
From:   Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To:     Jeremy Linton <jeremy.linton@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>, linux-mm@...ck.org,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        rientjes@...gle.com, Christoph Hellwig <hch@....de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:     linux-rpi-kernel <linux-rpi-kernel@...ts.infradead.org>
Subject: Re: [BUG] XHCI getting ZONE_DMA32 memory > than its bus_dma_limit

Hi Jeremy,
thanks for the bug report.

Just for the record the offending commit is: c84dc6e68a1d2 ("dma-pool: add
additional coherent pools to map to gfp mask").

On Thu, 2020-07-02 at 12:49 -0500, Jeremy Linton wrote:
> Hi,
> 
> Using 5.8rc3:
> 
> The rpi4 has a 3G dev->bus_dma_limit on its XHCI controller. With a usb3 
> hub, plus a few devices plugged in, randomly devices will fail 
> operations. This appears to because xhci_alloc_container_ctx() is 
> getting buffers > 3G via dma_pool_zalloc().
> 
> Tracking that down, it seems to be caused by dma_alloc_from_pool() using 
> dev_to_pool()->dma_direct_optimal_gfp_mask() to "optimistically" select 
> the atomic_pool_dma32 but then failing to verify that the allocations in 
> the pool are less than the dev bus_dma_limit.

I can reproduce this too.

The way I see it, dev_to_pool() wants a strict dma_direct_optimal_gfp_mask()
that is never wrong, since it's going to stick to that pool for the device's
lifetime. I've been looking at how to implement it, and it's not so trivial as
I can't see a failproof way to make a distinction between who needs DMA32 and
who is OK with plain KERNEL memory.

Otherwise, as Jeremy points out, the patch needs to implement allocations with
an algorithm similar to __dma_direct_alloc_pages()'s, which TBH I don't know if
it's a little overkill for the atomic context.

Short of finding a fix in the coming rc's, I suggest we revert this.

Regards,
Nicolas

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)