From: Jason Gunthorpe <jgg@ziepe.ca>
To: Christoph Hellwig <hch@infradead.org>
Cc: Leon Romanovsky <leon@kernel.org>,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
zyjzyj2000@gmail.com, Daisuke Matsuda <dskmtsd@gmail.com>
Subject: Re: [PATCH for-next v3] RDMA/core: Avoid hmm_dma_map_alloc() for virtual DMA devices
Date: Mon, 26 May 2025 16:57:17 -0300 [thread overview]
Message-ID: <20250526195717.GH12328@ziepe.ca> (raw)
In-Reply-To: <aDQQyjJv9YKK_ZoV@infradead.org>
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
prev parent reply other threads:[~2025-05-26 19:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-24 14:43 [PATCH for-next v3] RDMA/core: Avoid hmm_dma_map_alloc() for virtual DMA devices Daisuke Matsuda
2025-05-24 21:27 ` Greg Sword
2025-05-25 2:54 ` Daisuke Matsuda
2025-05-26 17:51 ` Greg Sword
2025-05-25 6:05 ` Leon Romanovsky
2025-05-26 17:52 ` Greg Sword
2025-05-27 6:35 ` Leon Romanovsky
2025-05-25 5:22 ` Zhu Yanjun
2025-05-25 6:03 ` Daisuke Matsuda
2025-05-25 14:17 ` Zhu Yanjun
2025-05-25 7:08 ` Leon Romanovsky
2025-05-25 9:34 ` Daisuke Matsuda
2025-05-25 10:24 ` Leon Romanovsky
2025-05-25 7:51 ` Leon Romanovsky
2025-05-26 6:57 ` Christoph Hellwig
2025-05-26 9:07 ` Leon Romanovsky
2025-05-26 19:57 ` Jason Gunthorpe [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250526195717.GH12328@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=dskmtsd@gmail.com \
--cc=hch@infradead.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=zyjzyj2000@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox