Re: [PATCH net v5 1/4] net: devmem: unmap dma_buf synchronously on queue uninstall
From: Paolo Abeni
Date: Mon Nov 02 2026 - 18:06:55 EST
On 11/2/26 19:58, Mina Almasry wrote:
On Mon, Nov 2, 2026 at 7:29 AM Paolo Abeni <pabeni@xxxxxxxxxx> wrote:I hoped for something smaller :)
On 11/2/26 00:16, Mina Almasry wrote:
On Sun, Nov 1, 2026 at 3:01 PM <netdev-bot+sashiko@xxxxxxxxxx> wrote:Will such follow-up rework the code touched by current patch/series?
- [High] The dma_dev use-after-free this patch says it fixes can still
happen for RX bindings made on a virtual device that leases queues,...
I know about the issues with leased devices. That needs a bit of a
rework, which I have done locally, and would like to send out as a
follow up fix.
how much? I'm under the impression that at least the fix for the issue
reported here would be quite overlapping.
/P
I pushed the follow-up branch on top of v5 here so you can see the exact diff:
https://github.com/mina/linux/compare/devmem-teardown-v4...devmem-lease-bind-map-dev
(commits: https://github.com/mina/linux/commits/devmem-lease-bind-map-dev)
There is some overlap (~55 lines of v5 touched across a 6-patch +262/-99
follow-up): it renames binding->dev/vdev to binding->map_dev/bind_dev, passes
the net_device explicitly to net_devmem_lock_dev(), factors out
net_devmem_close_rxqs(), and replaces the !rxq->lease / !netif_is_queue_leasee()
skips in net_devmem_dev_unregister() and mp_dmabuf_devmem_uninstall().
I kept it separate only to keep this net fix smaller and easier to review,
since the lease issue is pre-existing. Happy to either land v5 first and send
those 6 patches right after, or fold them into a v6 if you prefer avoiding the
churn.
I definitely would not fold the 2 series.
I'm wondering if this could be considered net-next material? pointing to
net-next will offer better guarantees for all the work to land in the same
release (no need to repost in such a case, I can apply this one to net-next
directly).
/P