All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: selftests: Make sure kvm_create_max_vcpus test won't hit RLIMIT_NOFILE
Date: Mon, 22 Nov 2021 17:38:01 +0000	[thread overview]
Message-ID: <YZvVeW6qYNb/kkSc@google.com> (raw)
In-Reply-To: <20211122171920.603760-1-vkuznets@redhat.com>

On Mon, Nov 22, 2021, Vitaly Kuznetsov wrote:
> With the elevated 'KVM_CAP_MAX_VCPUS' value kvm_create_max_vcpus test
> may hit RLIMIT_NOFILE limits:
> 
>  # ./kvm_create_max_vcpus
>  KVM_CAP_MAX_VCPU_ID: 4096
>  KVM_CAP_MAX_VCPUS: 1024
>  Testing creating 1024 vCPUs, with IDs 0...1023.
>  /dev/kvm not available (errno: 24), skipping test
> 
> Adjust RLIMIT_NOFILE limits to make sure KVM_CAP_MAX_VCPUS fds can be
> opened. Note, raising hard limit ('rlim_max') requires CAP_SYS_RESOURCE
> capability which is generally not needed to run kvm selftests (but without
> raising the limit the test is doomed to fail anyway).
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
>  .../selftests/kvm/kvm_create_max_vcpus.c      | 22 +++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/tools/testing/selftests/kvm/kvm_create_max_vcpus.c b/tools/testing/selftests/kvm/kvm_create_max_vcpus.c
> index f968dfd4ee88..19198477a10e 100644
> --- a/tools/testing/selftests/kvm/kvm_create_max_vcpus.c
> +++ b/tools/testing/selftests/kvm/kvm_create_max_vcpus.c
> @@ -12,6 +12,7 @@
>  #include <stdio.h>
>  #include <stdlib.h>
>  #include <string.h>
> +#include <sys/resource.h>
>  
>  #include "test_util.h"
>  
> @@ -19,6 +20,9 @@
>  #include "asm/kvm.h"
>  #include "linux/kvm.h"
>  
> +/* 'Safe' number of open file descriptors in addition to vCPU fds needed */
> +#define NOFD 16

Any reason not to make this "buffer" extra large, e.g. 100+ to avoid having to
debug this issue again in the future?

> +
>  void test_vcpu_creation(int first_vcpu_id, int num_vcpus)
>  {
>  	struct kvm_vm *vm;
> @@ -40,10 +44,28 @@ int main(int argc, char *argv[])
>  {
>  	int kvm_max_vcpu_id = kvm_check_cap(KVM_CAP_MAX_VCPU_ID);
>  	int kvm_max_vcpus = kvm_check_cap(KVM_CAP_MAX_VCPUS);

Rather than a separate define that's hard to describe succintly, what about:

	int nr_fds_wanted = kvm_max_vcpus + <arbitrary number>

and then the body becomes

	if (nr_fds_wanted > rl.rlim_cur) {
		rl.rlim_cur = nr_fds_wanted;
		rl.rlim_max = max(rl.rlim_max, nr_fds_wanted);

		...
	}

> +	struct rlimit rl;
>  
>  	pr_info("KVM_CAP_MAX_VCPU_ID: %d\n", kvm_max_vcpu_id);
>  	pr_info("KVM_CAP_MAX_VCPUS: %d\n", kvm_max_vcpus);
>  
> +	/*
> +	 * Creating KVM_CAP_MAX_VCPUS vCPUs require KVM_CAP_MAX_VCPUS open
> +	 * file decriptors.
> +	 */
> +	TEST_ASSERT(!getrlimit(RLIMIT_NOFILE, &rl),
> +		    "getrlimit() failed (errno: %d)", errno);

And strerror() output too?

> +
> +	if (kvm_max_vcpus > rl.rlim_cur - NOFD) {
> +		rl.rlim_cur = kvm_max_vcpus + NOFD;
> +
> +		if (kvm_max_vcpus > rl.rlim_max - NOFD)
> +			rl.rlim_max = kvm_max_vcpus + NOFD;
> +
> +		TEST_ASSERT(!setrlimit(RLIMIT_NOFILE, &rl),
> +			    "setrlimit() failed (errno: %d)", errno);
> +	}
> +
>  	/*
>  	 * Upstream KVM prior to 4.8 does not support KVM_CAP_MAX_VCPU_ID.
>  	 * Userspace is supposed to use KVM_CAP_MAX_VCPUS as the maximum ID
> -- 
> 2.33.1
> 

  reply	other threads:[~2021-11-22 17:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-22 17:19 [PATCH] KVM: selftests: Make sure kvm_create_max_vcpus test won't hit RLIMIT_NOFILE Vitaly Kuznetsov
2021-11-22 17:38 ` Sean Christopherson [this message]
2021-11-22 18:03   ` Vitaly Kuznetsov
2021-11-23 13:52     ` Vitaly Kuznetsov

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=YZvVeW6qYNb/kkSc@google.com \
    --to=seanjc@google.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.