All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Marc Zyngier <maz@kernel.org>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	Jintack Lim <jintack.lim@linaro.org>,
	Christoffer Dall <christoffer.dall@arm.com>
Subject: [arm-platforms:kvm-arm64/nv-6.8-nv2-only 25/50] arch/arm64/kvm/at.c:105:2: warning: variable 'fail' is used uninitialized whenever switch default is taken
Date: Wed, 22 Nov 2023 03:36:29 +0800	[thread overview]
Message-ID: <202311220207.7mxv9oyk-lkp@intel.com> (raw)

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/nv-6.8-nv2-only
head:   759d2e18f8954f4c76eb1772f38301df6ed8fa5d
commit: 720f083d74cd676abc4c424349c4e1c74c3df2cf [25/50] KVM: arm64: nv: Trap and emulate AT instructions from virtual EL2
config: arm64-allmodconfig (https://download.01.org/0day-ci/archive/20231122/202311220207.7mxv9oyk-lkp@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231122/202311220207.7mxv9oyk-lkp@intel.com/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@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311220207.7mxv9oyk-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> arch/arm64/kvm/at.c:105:2: warning: variable 'fail' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
     105 |         default:
         |         ^~~~~~~
   arch/arm64/kvm/at.c:110:7: note: uninitialized use occurs here
     110 |         if (!fail)
         |              ^~~~
   arch/arm64/kvm/at.c:49:11: note: initialize the variable 'fail' to silence this warning
      49 |         bool fail;
         |                  ^
         |                   = 0
   1 warning generated.


vim +/fail +105 arch/arm64/kvm/at.c

    43	
    44	void __kvm_at_s1e01(struct kvm_vcpu *vcpu, u32 op, u64 vaddr)
    45	{
    46		struct kvm_cpu_context *ctxt = &vcpu->arch.ctxt;
    47		struct mmu_config config;
    48		struct kvm_s2_mmu *mmu;
    49		bool fail;
    50	
    51		write_lock(&vcpu->kvm->mmu_lock);
    52	
    53		/*
    54		 * If HCR_EL2.{E2H,TGE} == {1,1}, the MMU context is already
    55		 * the right one (as we trapped from vEL2).
    56		 */
    57		if (vcpu_el2_e2h_is_set(vcpu) && vcpu_el2_tge_is_set(vcpu))
    58			goto skip_mmu_switch;
    59	
    60		/*
    61		 * FIXME: Obtaining the S2 MMU for a L2 is horribly racy, and
    62		 * we may not find it (recycled by another vcpu, for example).
    63		 * See the other FIXME comment below about the need for a SW
    64		 * PTW in this case.
    65		 */
    66		mmu = lookup_s2_mmu(vcpu);
    67		if (WARN_ON(!mmu))
    68			goto out;
    69	
    70		/* We've trapped, so everything is live on the CPU. */
    71		__mmu_config_save(&config);
    72	
    73		write_sysreg_el1(ctxt_sys_reg(ctxt, TTBR0_EL1),	SYS_TTBR0);
    74		write_sysreg_el1(ctxt_sys_reg(ctxt, TTBR1_EL1),	SYS_TTBR1);
    75		write_sysreg_el1(ctxt_sys_reg(ctxt, TCR_EL1),	SYS_TCR);
    76		write_sysreg_el1(ctxt_sys_reg(ctxt, SCTLR_EL1),	SYS_SCTLR);
    77		write_sysreg(kvm_get_vttbr(mmu),		vttbr_el2);
    78		/*
    79		 * REVISIT: do we need anything from the guest's VTCR_EL2? If
    80		 * looks like keeping the hosts configuration is the right
    81		 * thing to do at this stage (and we could avoid save/restore
    82		 * it. Keep the host's version for now.
    83		 */
    84		write_sysreg((config.hcr & ~HCR_TGE) | HCR_VM,	hcr_el2);
    85	
    86		isb();
    87	
    88	skip_mmu_switch:
    89	
    90		switch (op) {
    91		case OP_AT_S1E1R:
    92		case OP_AT_S1E1RP:
    93			fail = __kvm_at("s1e1r", vaddr);
    94			break;
    95		case OP_AT_S1E1W:
    96		case OP_AT_S1E1WP:
    97			fail = __kvm_at("s1e1w", vaddr);
    98			break;
    99		case OP_AT_S1E0R:
   100			fail = __kvm_at("s1e0r", vaddr);
   101			break;
   102		case OP_AT_S1E0W:
   103			fail = __kvm_at("s1e0w", vaddr);
   104			break;
 > 105		default:
   106			WARN_ON_ONCE(1);
   107			break;
   108		}
   109	
   110		if (!fail)
   111			ctxt_sys_reg(ctxt, PAR_EL1) = read_sysreg(par_el1);
   112		else
   113			ctxt_sys_reg(ctxt, PAR_EL1) = SYS_PAR_EL1_F;
   114	
   115		/*
   116		 * Failed? let's leave the building now.
   117		 *
   118		 * FIXME: how about a failed translation because the shadow S2
   119		 * wasn't populated? We may need to perform a SW PTW,
   120		 * populating our shadow S2 and retry the instruction.
   121		 */
   122		if (ctxt_sys_reg(ctxt, PAR_EL1) & SYS_PAR_EL1_F)
   123			goto nopan;
   124	
   125		/* No PAN? No problem. */
   126		if (!vcpu_el2_e2h_is_set(vcpu) || !(*vcpu_cpsr(vcpu) & PSR_PAN_BIT))
   127			goto nopan;
   128	
   129		/*
   130		 * For PAN-involved AT operations, perform the same
   131		 * translation, using EL0 this time.
   132		 */
   133		switch (op) {
   134		case OP_AT_S1E1RP:
   135			fail = __kvm_at("s1e0r", vaddr);
   136			break;
   137		case OP_AT_S1E1WP:
   138			fail = __kvm_at("s1e0w", vaddr);
   139			break;
   140		default:
   141			goto nopan;
   142		}
   143	
   144		/*
   145		 * If the EL0 translation has succeeded, we need to pretend
   146		 * the AT operation has failed, as the PAN setting forbids
   147		 * such a translation.
   148		 *
   149		 * FIXME: we hardcode a Level-3 permission fault. We really
   150		 * should return the real fault level.
   151		 */
   152		if (fail || !(read_sysreg(par_el1) & SYS_PAR_EL1_F))
   153			ctxt_sys_reg(ctxt, PAR_EL1) = (0xf << 1) | SYS_PAR_EL1_F;
   154	
   155	nopan:
   156		if (!(vcpu_el2_e2h_is_set(vcpu) && vcpu_el2_tge_is_set(vcpu)))
   157			__mmu_config_restore(&config);
   158	
   159	out:
   160		write_unlock(&vcpu->kvm->mmu_lock);
   161	}
   162	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

WARNING: multiple messages have this Message-ID (diff)
From: kernel test robot <lkp@intel.com>
To: Marc Zyngier <maz@kernel.org>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	Jintack Lim <jintack.lim@linaro.org>,
	Christoffer Dall <christoffer.dall@arm.com>
Subject: [arm-platforms:kvm-arm64/nv-6.8-nv2-only 25/50] arch/arm64/kvm/at.c:105:2: warning: variable 'fail' is used uninitialized whenever switch default is taken
Date: Wed, 22 Nov 2023 03:36:29 +0800	[thread overview]
Message-ID: <202311220207.7mxv9oyk-lkp@intel.com> (raw)

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/nv-6.8-nv2-only
head:   759d2e18f8954f4c76eb1772f38301df6ed8fa5d
commit: 720f083d74cd676abc4c424349c4e1c74c3df2cf [25/50] KVM: arm64: nv: Trap and emulate AT instructions from virtual EL2
config: arm64-allmodconfig (https://download.01.org/0day-ci/archive/20231122/202311220207.7mxv9oyk-lkp@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231122/202311220207.7mxv9oyk-lkp@intel.com/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@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311220207.7mxv9oyk-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> arch/arm64/kvm/at.c:105:2: warning: variable 'fail' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
     105 |         default:
         |         ^~~~~~~
   arch/arm64/kvm/at.c:110:7: note: uninitialized use occurs here
     110 |         if (!fail)
         |              ^~~~
   arch/arm64/kvm/at.c:49:11: note: initialize the variable 'fail' to silence this warning
      49 |         bool fail;
         |                  ^
         |                   = 0
   1 warning generated.


vim +/fail +105 arch/arm64/kvm/at.c

    43	
    44	void __kvm_at_s1e01(struct kvm_vcpu *vcpu, u32 op, u64 vaddr)
    45	{
    46		struct kvm_cpu_context *ctxt = &vcpu->arch.ctxt;
    47		struct mmu_config config;
    48		struct kvm_s2_mmu *mmu;
    49		bool fail;
    50	
    51		write_lock(&vcpu->kvm->mmu_lock);
    52	
    53		/*
    54		 * If HCR_EL2.{E2H,TGE} == {1,1}, the MMU context is already
    55		 * the right one (as we trapped from vEL2).
    56		 */
    57		if (vcpu_el2_e2h_is_set(vcpu) && vcpu_el2_tge_is_set(vcpu))
    58			goto skip_mmu_switch;
    59	
    60		/*
    61		 * FIXME: Obtaining the S2 MMU for a L2 is horribly racy, and
    62		 * we may not find it (recycled by another vcpu, for example).
    63		 * See the other FIXME comment below about the need for a SW
    64		 * PTW in this case.
    65		 */
    66		mmu = lookup_s2_mmu(vcpu);
    67		if (WARN_ON(!mmu))
    68			goto out;
    69	
    70		/* We've trapped, so everything is live on the CPU. */
    71		__mmu_config_save(&config);
    72	
    73		write_sysreg_el1(ctxt_sys_reg(ctxt, TTBR0_EL1),	SYS_TTBR0);
    74		write_sysreg_el1(ctxt_sys_reg(ctxt, TTBR1_EL1),	SYS_TTBR1);
    75		write_sysreg_el1(ctxt_sys_reg(ctxt, TCR_EL1),	SYS_TCR);
    76		write_sysreg_el1(ctxt_sys_reg(ctxt, SCTLR_EL1),	SYS_SCTLR);
    77		write_sysreg(kvm_get_vttbr(mmu),		vttbr_el2);
    78		/*
    79		 * REVISIT: do we need anything from the guest's VTCR_EL2? If
    80		 * looks like keeping the hosts configuration is the right
    81		 * thing to do at this stage (and we could avoid save/restore
    82		 * it. Keep the host's version for now.
    83		 */
    84		write_sysreg((config.hcr & ~HCR_TGE) | HCR_VM,	hcr_el2);
    85	
    86		isb();
    87	
    88	skip_mmu_switch:
    89	
    90		switch (op) {
    91		case OP_AT_S1E1R:
    92		case OP_AT_S1E1RP:
    93			fail = __kvm_at("s1e1r", vaddr);
    94			break;
    95		case OP_AT_S1E1W:
    96		case OP_AT_S1E1WP:
    97			fail = __kvm_at("s1e1w", vaddr);
    98			break;
    99		case OP_AT_S1E0R:
   100			fail = __kvm_at("s1e0r", vaddr);
   101			break;
   102		case OP_AT_S1E0W:
   103			fail = __kvm_at("s1e0w", vaddr);
   104			break;
 > 105		default:
   106			WARN_ON_ONCE(1);
   107			break;
   108		}
   109	
   110		if (!fail)
   111			ctxt_sys_reg(ctxt, PAR_EL1) = read_sysreg(par_el1);
   112		else
   113			ctxt_sys_reg(ctxt, PAR_EL1) = SYS_PAR_EL1_F;
   114	
   115		/*
   116		 * Failed? let's leave the building now.
   117		 *
   118		 * FIXME: how about a failed translation because the shadow S2
   119		 * wasn't populated? We may need to perform a SW PTW,
   120		 * populating our shadow S2 and retry the instruction.
   121		 */
   122		if (ctxt_sys_reg(ctxt, PAR_EL1) & SYS_PAR_EL1_F)
   123			goto nopan;
   124	
   125		/* No PAN? No problem. */
   126		if (!vcpu_el2_e2h_is_set(vcpu) || !(*vcpu_cpsr(vcpu) & PSR_PAN_BIT))
   127			goto nopan;
   128	
   129		/*
   130		 * For PAN-involved AT operations, perform the same
   131		 * translation, using EL0 this time.
   132		 */
   133		switch (op) {
   134		case OP_AT_S1E1RP:
   135			fail = __kvm_at("s1e0r", vaddr);
   136			break;
   137		case OP_AT_S1E1WP:
   138			fail = __kvm_at("s1e0w", vaddr);
   139			break;
   140		default:
   141			goto nopan;
   142		}
   143	
   144		/*
   145		 * If the EL0 translation has succeeded, we need to pretend
   146		 * the AT operation has failed, as the PAN setting forbids
   147		 * such a translation.
   148		 *
   149		 * FIXME: we hardcode a Level-3 permission fault. We really
   150		 * should return the real fault level.
   151		 */
   152		if (fail || !(read_sysreg(par_el1) & SYS_PAR_EL1_F))
   153			ctxt_sys_reg(ctxt, PAR_EL1) = (0xf << 1) | SYS_PAR_EL1_F;
   154	
   155	nopan:
   156		if (!(vcpu_el2_e2h_is_set(vcpu) && vcpu_el2_tge_is_set(vcpu)))
   157			__mmu_config_restore(&config);
   158	
   159	out:
   160		write_unlock(&vcpu->kvm->mmu_lock);
   161	}
   162	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2023-11-21 19:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-21 19:36 kernel test robot [this message]
2023-11-21 19:36 ` [arm-platforms:kvm-arm64/nv-6.8-nv2-only 25/50] arch/arm64/kvm/at.c:105:2: warning: variable 'fail' is used uninitialized whenever switch default is taken kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202311220207.7mxv9oyk-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=christoffer.dall@arm.com \
    --cc=jintack.lim@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=llvm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oe-kbuild-all@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.