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]>; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: Re: [PATCH v2 1/1] vhost: tolerate file descriptor in 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 spec's
> > > > compatibility clause was written for exactly this situation — any
> > > > front-end could make the same mistake. QEMU's libvhost-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 hit 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 message.
Agreed that security comes first. The patch does close the fd immediately via
close_msg_fds(ctx), so there's no leak risk. Happy to add a log message 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), closing",
ctx->fd_num);
close_msg_fds(ctx);
Would that address your concern? I'll include it in v4.
