From: Stephen Hemminger <stephen@networkplumber.org>
To: <pravin.bathija@dell.com>
Cc: <dev@dpdk.org>, <thomas@monjalon.net>,
<maxime.coquelin@redhat.com>, <fengchengwen@huawei.com>
Subject: Re: [PATCH v10 4/5] vhost_user: Function defs for add/rem mem regions
Date: Mon, 4 May 2026 09:01:20 -0700 [thread overview]
Message-ID: <20260504090120.2c00c986@phoenix.local> (raw)
In-Reply-To: <20260407224205.3910803-5-pravin.bathija@dell.com>
On Tue, 7 Apr 2026 22:42:04 +0000
<pravin.bathija@dell.com> wrote:
> From: Pravin M Bathija <pravin.bathija@dell.com>
>
> These changes cover the function definition for add/remove memory
> region calls which are invoked on receiving vhost user message from
> vhost user front-end (e.g. Qemu). In our case, in addition to testing
> with qemu front-end, the testing has also been performed with libblkio
> front-end and spdk/dpdk back-end. We did I/O using libblkio based device
> driver, to spdk based drives. There are also changes for set_mem_table
> and new definition for get memory slots. Our changes optimize the set
> memory table call to use common support functions. Message get memory
> slots is how the vhost-user front-end queries the vhost-user back-end
> about the number of memory slots available to be registered by the
> back-end. In addition support function to invalidate vring is also
> defined which is used in add/remove memory region functions.
>
> Signed-off-by: Pravin M Bathija <pravin.bathija@dell.com>
> ---
The rest of the series review cleanly but AI flagged one issue.
The initial description was a mess. Asked it to be clearer.
## Review: PATCH v10 4/5 — vhost_user: Function defs for add/rem mem regions
**Warning: incomplete cleanup in `vhost_user_add_mem_reg()` mmap-failure path.**
What is wrong: when `vhost_user_mmap_region()` returns -1, the handler
only closes `reg->fd`. But `vhost_user_mmap_region()` can fail *after*
setting `reg->mmap_addr`/`mmap_size`/`host_user_addr` and after
`add_guest_pages()` has appended entries (the `add_one_guest_page()`
realloc path).
Impact: leaked mmap and stale `dev->guest_pages` entries. Since
`nregions` is not incremented, the next ADD_MEM_REG reuses the same
slot and overwrites `mmap_addr`, so `free_all_mem_regions()` can no
longer reach the original mapping.
Fix: when `reg->mmap_addr` is set, take the `free_new_region` path
(`remove_guest_pages()` + `free_mem_region(reg)`) instead of just
`close(reg->fd)`. Keep the explicit `close()` for the case where
`mmap()` itself failed before `mmap_addr` was assigned.
next prev parent reply other threads:[~2026-05-04 16:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 22:42 [PATCH v10 0/5] Support add/remove memory region and get-max-slots pravin.bathija
2026-04-07 22:42 ` [PATCH v10 1/5] vhost: add user to mailmap and define to vhost hdr pravin.bathija
2026-04-07 22:42 ` [PATCH v10 2/5] vhost_user: header defines for add/rem mem region pravin.bathija
2026-04-07 22:42 ` [PATCH v10 3/5] vhost_user: support function defines for back-end pravin.bathija
2026-04-07 22:42 ` [PATCH v10 4/5] vhost_user: Function defs for add/rem mem regions pravin.bathija
2026-05-04 16:01 ` Stephen Hemminger [this message]
2026-05-05 5:54 ` Bathija, Pravin
2026-04-07 22:42 ` [PATCH v10 5/5] vhost_user: enable configure memory slots pravin.bathija
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260504090120.2c00c986@phoenix.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=maxime.coquelin@redhat.com \
--cc=pravin.bathija@dell.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox