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,
