linux-kernel - Re: [PATCH for-next v3] RDMA/core: Avoid hmm_dma_map

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: <20250526195717.GH12328@ziepe.ca>
Date: Mon, 26 May 2025 16:57:17 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Christoph Hellwig <hch@...radead.org>
Cc: Leon Romanovsky <leon@...nel.org>, linux-kernel@...r.kernel.org,
	linux-rdma@...r.kernel.org, zyjzyj2000@...il.com,
	Daisuke Matsuda <dskmtsd@...il.com>
Subject: Re: [PATCH for-next v3] RDMA/core: Avoid hmm_dma_map_alloc() for
 virtual DMA devices

On Sun, May 25, 2025 at 11:57:14PM -0700, Christoph Hellwig wrote:
> On Sun, May 25, 2025 at 03:51:08AM -0400, Leon Romanovsky wrote:
> > 
> > On Sat, 24 May 2025 14:43:28 +0000, Daisuke Matsuda wrote:
> > > Drivers such as rxe, which use virtual DMA, must not call into the DMA
> > > mapping core since they lack physical DMA capabilities. Otherwise, a NULL
> > > pointer dereference is observed as shown below. This patch ensures the RDMA
> > > core handles virtual and physical DMA paths appropriately.
> > > 
> > > This fixes the following kernel oops:
> > > 
> > > [...]
> > 
> > Applied, thanks!
> 
> So while this version look correct, the idea of open coding the
> virtual device version of hmm_dma_map directly in the ODP code
> is a nasty leaky abstraction.  Please pull it into a proper ib_dma_*
> wrapper.

IMHO the ib_dma_* family was intended to be a ULP facing API so that
verbs using drivers can pass the right information through the WQE
APIs. Inside a driver it should not be calling these functions.

I think the bigger issue is that the virt drivers all expect to be
working in terms of struct page. It doesn't make any sense that rxe
would be using struct hmm_dma_map *at all*.

Indeed maybe it shouldn't even be using ib_umem_odp at all, since
basically everything it needs to do is different.

The nasty bit here is trying to make umem_odp overload struct
hmm_dma_map to also handle a struct page * array for the virtual
drivers.

Jason