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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 20 Nov 2022 14:41:45 -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 11:49 AM, Dean Luick wrote: > 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. I have tested the proposed hfi1 changes. They are fine. Acked-by: Dean Luick <dean.luick@...nelisnetworks.com> Tested-by: Dean Luick <dean.luick@...nelisnetworks.com> Using dma_mmap_*() for the changed cases (e.g. rcvhdrq) fails. They are being looked at. I don't think they need to be part of this change. -Dean External recipient
Powered by blists - more mailing lists