On 13.11.25 13:38, Stefano Garzarella wrote:
On Thu, Nov 13, 2025 at 12:56:39PM +0100, David Hildenbrand (Red Hat) wrote:
On 13.11.25 10:40, Stefano Garzarella wrote:
CCing David
Thanks
On Thu, Nov 13, 2025 at 11:58:42AM +0300, Daniil Tatianin wrote:
Just having a file descriptor is not enough to consider a memory region
public. If QEMU didn't map it as MAP_SHARED (in case of share=off), guest
writes to this region won't be visible to the vhost-user backend, thus
causing it to read all zeroes or garbage. Make sure we don't pass such
regions and include that to our definition of what a private region is.
Should we add a Fixes tag? Not really as bug fix, but more to make it
clear that this is a followup.
Fixes: 552b25229c ("vhost: Rework memslot filtering and fix "used_memslot"
tracking")
I am missing a description of what this problem is fixing.
The thing is that having real MAP_PRIVATE memory in such VM
configurations is usually a strong indication that it is a
VM-misconfiguration.
E.g., a vhost-user device cannot possibly read/write that memory.
So before we call something a fix (that was spelled out as a TODO), I
want to learn more about the valid sue case we have in mind here.
I specified in my comment: "Not really as bug fix, but more to make it
clear that this is a followup.", so I agree it is not a fix. But, IMO
it's nice to link a follow-up patch to the previous patch that
introduced the TODO. That said, yeah, maybe the Fixes tag is not the
right one, but at least I think we should mention that commit.
Right, the thing is that we already did before the code something wrong
if you take a look at the old vhost_user_mem_section_filter().
Passing MAP_PRIVATE memory to a vhost-user device and having it work on
the shared memory cannot possibly work correctly.
So IIUC, commit 552b25229cf didn't change the behavior, it only
highlighted the existing problem.
So I agree, resolving this TODO is great -- back then I wasn't quite
sure if there are other things we have to consider so I left it alone.
--
Cheers
David
