Hi Maxime, I noticed this patch is delegated to you. Could you please help review this patch and provide feedback ?
I'm hoping for this one line change to be merged soon into mainline and to 26.07 stable so it will make the upcoming SPDK release where it will be critical feature for the vhost/libblkio support. Much appreciated! Regards, Pravin Internal Use - Confidential > -----Original Message----- > From: Bathija, Pravin > Sent: Friday, July 31, 2026 10:16 AM > To: Stephen Hemminger <[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 > > > > > -----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.
