On Fri, Nov 8, 2024 at 5:45 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Thu, Nov 07, 2024, James Houghton wrote: > > On Wed, Nov 6, 2024 at 3:22 AM kernel test robot <lkp@xxxxxxxxx> wrote: > > > > > > Hi James, > > > > > > kernel test robot noticed the following build warnings: > > > > > > [auto build test WARNING on a27e0515592ec9ca28e0d027f42568c47b314784] > > > > > > url: https://github.com/intel-lab-lkp/linux/commits/James-Houghton/KVM-Remove-kvm_handle_hva_range-helper-functions/20241106-025133 > > > base: a27e0515592ec9ca28e0d027f42568c47b314784 > > > patch link: https://lore.kernel.org/r/20241105184333.2305744-5-jthoughton%40google.com > > > patch subject: [PATCH v8 04/11] KVM: x86/mmu: Relax locking for kvm_test_age_gfn and kvm_age_gfn > > > config: x86_64-rhel-8.3 (https://download.01.org/0day-ci/archive/20241106/202411061526.RAuCXKJh-lkp@xxxxxxxxx/config) > > > compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241106/202411061526.RAuCXKJh-lkp@xxxxxxxxx/reproduce) > > > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > > > the same patch/commit), kindly add following tags > > > | Reported-by: kernel test robot <lkp@xxxxxxxxx> > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202411061526.RAuCXKJh-lkp@xxxxxxxxx/ > > > > > > All warnings (new ones prefixed by >>): > > > > > > arch/x86/kvm/mmu/tdp_mmu.c: In function 'kvm_tdp_mmu_age_spte': > > > >> arch/x86/kvm/mmu/tdp_mmu.c:1189:23: warning: ignoring return value of '__tdp_mmu_set_spte_atomic' declared with attribute 'warn_unused_result' [-Wunused-result] > > > 1189 | (void)__tdp_mmu_set_spte_atomic(iter, new_spte); > > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > Well, I saw this compiler warning in my latest rebase and thought the > > `(void)` would fix it. I guess the next best way to fix it would be to > > assign to an `int __maybe_unused`. I'll do for a v9, or Sean if you're > > going to take the series (maybe? :)), go ahead and apply whatever fix > > you like. > > Heh, actually, the compiler is correct. Ignoring the return value is a bug. > KVM should instead return immediately, as falling through to the tracepoint will > log bogus information. E.g. will show a !PRESENT SPTE, instead of whatever the > current SPTE actually is (iter->old_spte will have been updating to the current > value of the SPTE). > > trace_kvm_tdp_mmu_spte_changed(iter->as_id, iter->gfn, iter->level, > iter->old_spte, new_spte); > > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c > index f5b4f1060fff..cc8ae998b7c8 100644 > --- a/arch/x86/kvm/mmu/tdp_mmu.c > +++ b/arch/x86/kvm/mmu/tdp_mmu.c > @@ -1186,7 +1186,8 @@ static void kvm_tdp_mmu_age_spte(struct tdp_iter *iter) > * It is safe for the following cmpxchg to fail. Leave the > * Accessed bit set, as the spte is most likely young anyway. > */ > - (void)__tdp_mmu_set_spte_atomic(iter, new_spte); > + if (__tdp_mmu_set_spte_atomic(iter, new_spte)) > + return; > } > > trace_kvm_tdp_mmu_spte_changed(iter->as_id, iter->gfn, iter->level, > Oh yes, you're right. Thanks Sean! The diff LGTM.
