Hi Maxime, Gentle reminder and follow up for this patch.
Thanks, Pravin Internal Use - Confidential > -----Original Message----- > From: Bathija, Pravin > Sent: Friday, August 7, 2026 2:19 PM > To: Maxime Coquelin <[email protected]> > Cc: 'David Marchand' <[email protected]>; '[email protected]' > <[email protected]>; '[email protected]' > <[email protected]>; '[email protected]' > <[email protected]>; '[email protected]' <[email protected]>; > '[email protected]' <[email protected]>; Stephen Hemminger > <[email protected]> > Subject: RE: [PATCH v2 1/1] vhost: tolerate file descriptor in REM_MEM_REG > msg > > 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 > > > -----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.
