netdev - Re: [PATCH 2/7] RDMA/hfi1: don't pass bogus GFP_ flags to dma_alloc

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:   Wed, 16 Nov 2022 11:49:21 -0600
From:   Dean Luick <dean.luick@...nelisnetworks.com>
To:     Christoph Hellwig <hch@....de>, Robin Murphy <robin.murphy@....com>
Cc:     Dennis Dalessandro <dennis.dalessandro@...nelisnetworks.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Alexandra Winter <wintera@...ux.ibm.com>,
        Wenjia Zhang <wenjia@...ux.ibm.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Russell King <linux@...linux.org.uk>,
        linux-arm-kernel@...ts.infradead.org, linux-rdma@...r.kernel.org,
        iommu@...ts.linux.dev, linux-media@...r.kernel.org,
        netdev@...r.kernel.org, linux-s390@...r.kernel.org,
        alsa-devel@...a-project.org
Subject: Re: [PATCH 2/7] RDMA/hfi1: don't pass bogus GFP_ flags to
 dma_alloc_coherent

On 11/16/2022 9:45 AM, Christoph Hellwig wrote:
> On Wed, Nov 16, 2022 at 03:15:10PM +0000, Robin Murphy wrote:
>> Coherent DMA buffers are allocated by a kernel driver or subsystem for the
>> use of a device managed by that driver or subsystem, and thus they
>> fundamentally belong to the kernel as proxy for the device. Any coherent
>> DMA buffer may be mapped to userspace with the dma_mmap_*() interfaces, but
>> they're never a "userspace allocation" in that sense.
>
> Exactly.  I could not find a place to map the buffers to userspace,
> so if it does that without using the proper interfaces we need to fix
> that as well.  Dean, can you point me to the mmap code?

See hfi1_file_mmap(), cases RCV_HDRQ and RCV_EGRBUF, for the two items you changed in hfi1.  Both directly use remap_pfn_range(), which is probably the original approved call, but now is now buried deep within dma_mmap_*().  As you say - these should be updated.  That said, the eager buffer mapping will stitch together multiple eager buffers into a single user map/vma.  I don't see how to do that with the dma_mmap_*() interface.

-Dean
External recipient