2015-08-12 19:06:22

by Alexander Graf

[permalink] [raw]
Subject: Re: [PATCH] kvm:powerpc:Fix return statements for wrapper functions in the file book3s_64_mmu_hv.c



On 10.08.15 17:27, Nicholas Krause wrote:
> This fixes the wrapper functions kvm_umap_hva_hv and the function
> kvm_unmap_hav_range_hv to return the return value of the function
> kvm_handle_hva or kvm_handle_hva_range that they are wrapped to
> call internally rather then always making the caller of these
> wrapper functions think they always run successfully by returning
> the value of zero directly.
>
> Signed-off-by: Nicholas Krause <[email protected]>

Paul, could you please take on this one?

Thanks,

Alex

> ---
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index dab68b7..0905c8f 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -774,14 +774,12 @@ static int kvm_unmap_rmapp(struct kvm *kvm, unsigned long *rmapp,
>
> int kvm_unmap_hva_hv(struct kvm *kvm, unsigned long hva)
> {
> - kvm_handle_hva(kvm, hva, kvm_unmap_rmapp);
> - return 0;
> + return kvm_handle_hva(kvm, hva, kvm_unmap_rmapp);
> }
>
> int kvm_unmap_hva_range_hv(struct kvm *kvm, unsigned long start, unsigned long end)
> {
> - kvm_handle_hva_range(kvm, start, end, kvm_unmap_rmapp);
> - return 0;
> + return kvm_handle_hva_range(kvm, start, end, kvm_unmap_rmapp);
> }
>
> void kvmppc_core_flush_memslot_hv(struct kvm *kvm,
>


2015-08-14 02:49:22

by Michael Ellerman

[permalink] [raw]
Subject: Re: [PATCH] kvm:powerpc:Fix return statements for wrapper functions in the file book3s_64_mmu_hv.c

On Wed, 2015-08-12 at 21:06 +0200, Alexander Graf wrote:
>
> On 10.08.15 17:27, Nicholas Krause wrote:
> > This fixes the wrapper functions kvm_umap_hva_hv and the function
> > kvm_unmap_hav_range_hv to return the return value of the function
> > kvm_handle_hva or kvm_handle_hva_range that they are wrapped to
> > call internally rather then always making the caller of these
> > wrapper functions think they always run successfully by returning
> > the value of zero directly.
> >
> > Signed-off-by: Nicholas Krause <[email protected]>
>
> Paul, could you please take on this one?

Paul's away for a while can you take it directly?

cheers