Re: [PATCH net v5 1/4] net: devmem: unmap dma_buf synchronously on queue uninstall

[Mina Almasry <almasrymina@google.com>]

On Mon, Nov 2, 2026 at 2:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On 11/2/26 19:58, Mina Almasry wrote:
> > On Mon, Nov 2, 2026 at 7:29 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >> On 11/2/26 00:16, Mina Almasry wrote:
> >>> On Sun, Nov 1, 2026 at 3:01 PM <netdev-bot+sashiko@kernel.org> wrote:
> >>>>
> >>>> - [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.
> >> Will such follow-up rework the code touched by  current patch/series?
> >> 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 hoped for something smaller :)
>
> 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).
>

I'm more than happy with net-next. Honestly so many AI-foudn fixes
requiring so many refactors that net-next makes sense most of the time
now, for me at least. Thank you Paolo!

-- 
Thanks,
Mina