Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Tue, 31 May 2022 19:39:23 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Thomas Huth <thuth@redhat.com>
Cc:     kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: Adjust the return type of
 kvm_vm_ioctl_check_extension_generic()
Message-ID: <YpZu6/k+8EydfBKf@google.com>
References: <20220531075540.14242-1-thuth@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220531075540.14242-1-thuth@redhat.com>
Precedence: bulk

On Tue, May 31, 2022, Thomas Huth wrote:
> kvm_vm_ioctl_check_extension_generic() either returns small constant
> numbers or the result of kvm_vm_ioctl_check_extension() which is of type
> "int". Looking at the callers of kvm_vm_ioctl_check_extension_generic(),
> one stores the result in "int r", the other one in "long r", so the
> result has to fit in the smaller "int" in any case. Thus let's adjust
> the return value to "int" here so we have one less transition from
> "int" -> "long" -> "int" in case of the kvm_vm_ioctl() ->
> kvm_vm_ioctl_check_extension_generic() -> kvm_vm_ioctl_check_extension()
> call chain.

LOL, I was going to play devil's advocate and say that it would be just as easy
to adjust kvm_vm_ioctl() to use "long r", but there's actually lurking bug, sort
of.

KVM_GET_NR_MMU_PAGES => kvm_vm_ioctl_get_nr_mmu_pages() returns an "unsigned long",
and it very much can be a value larger than an "int" because KVM_SET_NR_MMU_PAGES
allows setting an arbitrary value (it may also be possible for KVM's default to
be that large, but I don't feel like doing math).

But, the very original commit 82ce2c96831f ("KVM: Allow dynamic allocation of the
mmu shadow cache size") only tracked and returned an "unsigned int".  It was the
relatively recent commit bc8a3d8925a8 ("kvm: mmu: Fix overflow on kvm mmu page
limit calculation") that bumped the internal tracking to "unsigned long" and
overlooked the long/int mess.

Looking at other architectures, kvm_vm_ioctl_create_spapr_tce() also returns a
"long", but that's unnecessary as it only returns -errno or propagates "int" returns.

Ditto for kvm_arch_vm_ioctl_hv(), kvm_arch_vm_ioctl_pr(), and
kvm_vm_ioctl_mte_copy_tags().

Ignoring KVM_GET_NR_MMU_PAGES for the moment, I like the change, but would rather
phrase the justification along the lines of:

  KVM uses "long" return values for functions that are wired up to
  "struct file_operations", but otherwise uses "int" return values for
  functions that can return 0/-errno in order to avoid unintentional
  divergences between 32-bit and 64-bit kernels.

and then make the same change to kvm_arch_vm_ioctl() and all its subordinates.

As for KVM_GET_NR_MMU_PAGES, my vote would be just sweep it under the rug with a
comment and blurb in the documentation that it's broken.  I highly doubt any VMM
actually uses the ioctl() in any meaningful way as it was largely made obsolete by
two-dimensional paging, e.g. neither QEMU nor our VMM use it.

> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  This patch is of very low importance - if you don't like it, please just
>  ignore. I just came across this nit while looking through the code and
>  thought that it might be somewhat nicer this way.
> 
>  virt/kvm/kvm_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 64ec2222a196..e911331fc620 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -4309,7 +4309,7 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
>  	return 0;
>  }
>  
> -static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
> +static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
>  {
>  	switch (arg) {
>  	case KVM_CAP_USER_MEMORY:
> -- 
> 2.31.1
>