RE: [PATCH v2 1/1] vhost: tolerate file descriptor in REM_MEM_REG msg

Internal Use - Confidential
> -----Original Message-----
> From: Stephen Hemminger <[email protected]>
> Sent: Friday, July 31, 2026 8:28 AM
> To: Bathija, Pravin <[email protected]>
> Cc: David Marchand <[email protected]>; dev@=
-dpdk.org;
> [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: Re: [PATCH v2 1/1] vhost: tolerate file descriptor i=
n REM_MEM_REG
> msg
>
>
> [EXTERNAL EMAIL]
>
> On Fri, 31 Jul 2026 08:19:07 +0000
> "Bathija, Pravin" <[email protected]> wrote=
:
>
> > > > While the immediate motivation was libblkio, the sp=
ec's
> > > > compatibility clause was written for exactly this s=
ituation — any
> > > > front-end could make the same mistake. QEMU's libvh=
ost-user
> > > > reference implementation
> > > already tolerates it (see vu_rem_mem_reg).
> > >
> > > Which does not change that I dislike such compat.
> >
> > I couldn't agree with you more.  The libblkio fix is ready and =
will stop sending
> the fd.
> > In an ideal world we'd fix libblkio and move on,  but there are
> > already several released versions of libblkio in the wild that =
exhibit
> > this behavior.  Users pairing those with a current DPDK will hi=
t a broken
> connection with no obvious workaround.
>
> IMHO security safety trumps the specification in this case.
> Although it might help to document this somewhere and add a better me=
ssage.

Agreed that security comes first. The patch does close the fd immediately v=
ia
close_msg_fds(ctx), so there's no leak risk. Happy to add a log mes=
sage so it's visible when a
front-end sends an unexpected fd. Something like:

if (ctx->fd_num > 0)
    VHOST_CONFIG_LOG(dev->ifname, WARNING,
        "REM_MEM_REG received with %d unexpected fd(s), clo=
sing",
        ctx->fd_num);
close_msg_fds(ctx);

Would that address your concern? I'll include it in v4.