From: David Hildenbrand <david@redhat.com>
To: Daniil Tatianin <d-tatianin@yandex-team.ru>, qemu-devel@nongnu.org
Cc: imammedo@redhat.com, pbonzini@redhat.com, yc-core@yandex-team.ru,
sw@weilnetz.de
Subject: Re: [PATCH v1 1/2] hostmem: use a static size for maxnode, validate policy everywhere
Date: Tue, 7 Dec 2021 09:31:33 +0100 [thread overview]
Message-ID: <5a5ab29a-302e-2eaf-23d8-0de731842c41@redhat.com> (raw)
In-Reply-To: <20211207070607.1422670-1-d-tatianin@yandex-team.ru>
On 07.12.21 08:06, Daniil Tatianin wrote:
> Previously we would calculate the last set bit in the mask, and add
> 2 to that value to get the maxnode value. This is unnecessary since
> the mbind syscall allows the bitmap to be any (reasonable) size as
> long as all the unused bits are clear. This also adds policy validation
> in multiple places so that it's guaranteed to be valid when we call
> mbind.
>
> Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
> ---
> backends/hostmem.c | 64 +++++++++++++++++++++++++++++++---------------
> 1 file changed, 43 insertions(+), 21 deletions(-)
>
> diff --git a/backends/hostmem.c b/backends/hostmem.c
> index 4c05862ed5..392026efe6 100644
> --- a/backends/hostmem.c
> +++ b/backends/hostmem.c
> @@ -38,6 +38,29 @@ host_memory_backend_get_name(HostMemoryBackend *backend)
> return object_get_canonical_path(OBJECT(backend));
> }
>
> +static bool
> +validate_policy(HostMemPolicy policy, bool nodes_empty, Error **errp)
> +{
> + /*
> + * check for invalid host-nodes and policies and give more verbose
> + * error messages than mbind().
> + */
> + if (!nodes_empty && policy == MPOL_DEFAULT) {
> + error_setg(errp, "host-nodes must be empty for policy default,"
> + " or you should explicitly specify a policy other"
> + " than default");
> + return false;
> + }
> +
> + if (nodes_empty && policy != MPOL_DEFAULT) {
> + error_setg(errp, "host-nodes must be set for policy %s",
> + HostMemPolicy_str(policy));
> + return false;
> + }
> +
> + return true;
> +}
Hm, we set two properties individually but bail out when the current combination
is impossible, which is nasty. It means we have modify properties in the right order
(which will differ based on the policy) to make a change.
Do we have any sane use case of modifying the policy/host-nodes at runtime?
I mean, it's just completely wrong when we already have any memory
preallocated/touched inside the range, as we won't issue another mbind call.
I suggest instead to fix this hole:
diff --git a/backends/hostmem.c b/backends/hostmem.c
index 4c05862ed5..7edc3a075e 100644
--- a/backends/hostmem.c
+++ b/backends/hostmem.c
@@ -111,6 +111,11 @@ host_memory_backend_set_host_nodes(Object *obj, Visitor *v, const char *name,
HostMemoryBackend *backend = MEMORY_BACKEND(obj);
uint16List *l, *host_nodes = NULL;
+ if (host_memory_backend_mr_inited(backend)) {
+ error_setg(errp, "Property 'host-nodes' cannot be changed anymore.");
+ return;
+ }
+
visit_type_uint16List(v, name, &host_nodes, errp);
for (l = host_nodes; l; l = l->next) {
@@ -142,6 +147,12 @@ static void
host_memory_backend_set_policy(Object *obj, int policy, Error **errp)
{
HostMemoryBackend *backend = MEMORY_BACKEND(obj);
+
+ if (host_memory_backend_mr_inited(backend)) {
+ error_setg(errp, "Property 'policy' cannot be changed anymore.");
+ return;
+ }
+
backend->policy = policy;
#ifndef CONFIG_NUMA
--
Thanks,
David / dhildenb
prev parent reply other threads:[~2021-12-07 8:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-07 7:06 [PATCH v1 1/2] hostmem: use a static size for maxnode, validate policy everywhere Daniil Tatianin
2021-12-07 7:06 ` [PATCH v1 2/2] osdep: support mempolicy for preallocation in os_mem_prealloc Daniil Tatianin
2021-12-07 8:13 ` David Hildenbrand
[not found] ` <227321638883575@mail.yandex-team.ru>
2021-12-07 15:05 ` David Hildenbrand
2021-12-07 8:31 ` David Hildenbrand [this message]
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=5a5ab29a-302e-2eaf-23d8-0de731842c41@redhat.com \
--to=david@redhat.com \
--cc=d-tatianin@yandex-team.ru \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sw@weilnetz.de \
--cc=yc-core@yandex-team.ru \
/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;
as well as URLs for NNTP newsgroup(s).