Re: [PATCH v9 10/17] KVM: x86: Compute max_mapping_level with input from guest_memfd

[Sean Christopherson <seanjc@google.com>]

On Wed, May 21, 2025, Ackerley Tng wrote:
> >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> >> index de7b46ee1762..f9bb025327c3 100644
> >> --- a/include/linux/kvm_host.h
> >> +++ b/include/linux/kvm_host.h
> >> @@ -2560,6 +2560,7 @@ static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
> >>   int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> >>   		     gfn_t gfn, kvm_pfn_t *pfn, struct page **page,
> >>   		     int *max_order);
> >> +int kvm_gmem_mapping_order(const struct kvm_memory_slot *slot, gfn_t gfn);
> >>   #else
> >>   static inline int kvm_gmem_get_pfn(struct kvm *kvm,
> >>   				   struct kvm_memory_slot *slot, gfn_t gfn,
> >> @@ -2569,6 +2570,12 @@ static inline int kvm_gmem_get_pfn(struct kvm *kvm,
> >>   	KVM_BUG_ON(1, kvm);
> >>   	return -EIO;
> >>   }
> >> +static inline int kvm_gmem_mapping_order(const struct kvm_memory_slot *slot,
> >> +					 gfn_t gfn)
> >
> > Probably should indent with two tabs here.
> 
> Yup!

Nope!  :-)

In KVM, please align the indentation as you did.

 : Yeah, that way of indenting is rather bad practice. Especially for new
 : code we're adding or when we touch existing code, we should just use two
 : tabs.

 : That way, we can fit more stuff into a single line, and when doing
 : simple changes, such as renaming the function or changing the return
 : type, we won't have to touch all the parameters.

At the cost of readability, IMO.  The number of eyeballs that read the code is
orders of magnitude greater than the number of times a function's parameters end
up being shuffled around.  Sacrificing readability and consistenty to avoid a
small amount of rare churn isn't a good tradeoff.