All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: oe-kbuild-all@lists.linux.dev
Subject: [broonie-ci:arm64-sve-trap-mitigation 2/3] arch/arm64/kernel/fpsimd.c:365:23: warning: unused variable 'sve_vq_minus_one'
Date: Wed, 01 Jul 2026 22:43:57 +0200	[thread overview]
Message-ID: <202607012252.7JnbghOZ-lkp@intel.com> (raw)

Hi Mark,

FYI, the error/warning was bisected to this commit, please ignore it if it's irrelevant.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/ci.git arm64-sve-trap-mitigation
head:   00a72da058c10512a992dd75733d08daed8437fc
commit: 2927097df60b0ee11007db0ac60ffec3830e8bd3 [2/3] arm64/fpsimd: Suppress SVE access traps when loading FPSIMD state
config: arm64-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20260701/202607012252.7JnbghOZ-lkp@intel.com/config)
compiler: aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260701/202607012252.7JnbghOZ-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/202607012252.7JnbghOZ-lkp@intel.com/

All warnings (new ones prefixed by >>):

   arch/arm64/kernel/fpsimd.c: In function 'task_fpsimd_load':
>> arch/arm64/kernel/fpsimd.c:365:23: warning: unused variable 'sve_vq_minus_one' [-Wunused-variable]
     365 |         unsigned long sve_vq_minus_one;
         |                       ^~~~~~~~~~~~~~~~


vim +/sve_vq_minus_one +365 arch/arm64/kernel/fpsimd.c

   279	
   280	/*
   281	 * TIF_SME controls whether a task can use SME without trapping while
   282	 * in userspace, when TIF_SME is set then we must have storage
   283	 * allocated in sve_state and sme_state to store the contents of both ZA
   284	 * and the SVE registers for both streaming and non-streaming modes.
   285	 *
   286	 * If both SVCR.ZA and SVCR.SM are disabled then at any point we
   287	 * may disable TIF_SME and reenable traps.
   288	 */
   289	
   290	
   291	/*
   292	 * TIF_SVE controls whether a task can use SVE without trapping while
   293	 * in userspace, and also (together with TIF_SME) the way a task's
   294	 * FPSIMD/SVE state is stored in thread_struct.
   295	 *
   296	 * The kernel uses this flag to track whether a user task is actively
   297	 * using SVE, and therefore whether full SVE register state needs to
   298	 * be tracked.  If not, the cheaper FPSIMD context handling code can
   299	 * be used instead of the more costly SVE equivalents.
   300	 *
   301	 *  * TIF_SVE or SVCR.SM set:
   302	 *
   303	 *    The task can execute SVE instructions while in userspace without
   304	 *    trapping to the kernel.
   305	 *
   306	 *    During any syscall, the kernel may optionally clear TIF_SVE and
   307	 *    discard the vector state except for the FPSIMD subset.
   308	 *
   309	 *  * TIF_SVE clear:
   310	 *
   311	 *    An attempt by the user task to execute an SVE instruction causes
   312	 *    do_sve_acc() to be called, which does some preparation and then
   313	 *    sets TIF_SVE.
   314	 *
   315	 * During any syscall, the kernel may optionally clear TIF_SVE and
   316	 * discard the vector state except for the FPSIMD subset.
   317	 *
   318	 * The data will be stored in one of two formats:
   319	 *
   320	 *  * FPSIMD only - FP_STATE_FPSIMD:
   321	 *
   322	 *    When the FPSIMD only state stored task->thread.fp_type is set to
   323	 *    FP_STATE_FPSIMD, the FPSIMD registers V0-V31 are encoded in
   324	 *    task->thread.uw.fpsimd_state; bits [max : 128] for each of Z0-Z31 are
   325	 *    logically zero but not stored anywhere; P0-P15 and FFR are not
   326	 *    stored and have unspecified values from userspace's point of
   327	 *    view.  For hygiene purposes, the kernel zeroes them on next use,
   328	 *    but userspace is discouraged from relying on this.
   329	 *
   330	 *    task->thread.sve_state does not need to be non-NULL, valid or any
   331	 *    particular size: it must not be dereferenced and any data stored
   332	 *    there should be considered stale and not referenced.
   333	 *
   334	 *  * SVE state - FP_STATE_SVE:
   335	 *
   336	 *    When the full SVE state is stored task->thread.fp_type is set to
   337	 *    FP_STATE_SVE and Z0-Z31 (incorporating Vn in bits[127:0] or the
   338	 *    corresponding Zn), P0-P15 and FFR are encoded in in
   339	 *    task->thread.sve_state, formatted appropriately for vector
   340	 *    length task->thread.sve_vl or, if SVCR.SM is set,
   341	 *    task->thread.sme_vl. The storage for the vector registers in
   342	 *    task->thread.uw.fpsimd_state should be ignored.
   343	 *
   344	 *    task->thread.sve_state must point to a valid buffer at least
   345	 *    sve_state_size(task) bytes in size. The data stored in
   346	 *    task->thread.uw.fpsimd_state.vregs should be considered stale
   347	 *    and not referenced.
   348	 *
   349	 *  * FPSR and FPCR are always stored in task->thread.uw.fpsimd_state
   350	 *    irrespective of whether TIF_SVE is clear or set, since these are
   351	 *    not vector length dependent.
   352	 */
   353	
   354	/*
   355	 * Update current's FPSIMD/SVE registers from thread_struct.
   356	 *
   357	 * This function should be called only when the FPSIMD/SVE state in
   358	 * thread_struct is known to be up to date, when preparing to enter
   359	 * userspace.
   360	 */
   361	static void task_fpsimd_load(void)
   362	{
   363		bool restore_sve_regs = false;
   364		bool restore_ffr;
 > 365		unsigned long sve_vq_minus_one;
   366	
   367		WARN_ON(!system_supports_fpsimd());
   368		WARN_ON(preemptible());
   369		WARN_ON(test_thread_flag(TIF_KERNEL_FPSTATE));
   370	
   371		if (system_supports_sve() || system_supports_sme()) {
   372			switch (current->thread.fp_type) {
   373			case FP_STATE_FPSIMD:
   374				break;
   375			case FP_STATE_SVE:
   376				if (!thread_sm_enabled(&current->thread))
   377					WARN_ON_ONCE(!test_and_set_thread_flag(TIF_SVE));
   378	
   379				restore_sve_regs = true;
   380				restore_ffr = true;
   381				break;
   382			default:
   383				/*
   384				 * This indicates either a bug in
   385				 * fpsimd_save_user_state() or memory corruption, we
   386				 * should always record an explicit format
   387				 * when we save. We always at least have the
   388				 * memory allocated for FPSIMD registers so
   389				 * try that and hope for the best.
   390				 */
   391				WARN_ON_ONCE(1);
   392				clear_thread_flag(TIF_SVE);
   393				break;
   394			}
   395		}
   396	
   397		/*
   398		 * If SVE has been enabled we may keep it enabled even if
   399		 * loading only FPSIMD state, so always set the VL.
   400		 */
   401		if (system_supports_sve() && test_thread_flag(TIF_SVE)) {
   402			unsigned long vq = sve_vq_from_vl(task_get_sve_vl(current));
   403			sysreg_clear_set_s(SYS_ZCR_EL1, ZCR_ELx_LEN, vq - 1);
   404		}
   405	
   406		/* Restore SME, override SVE register configuration if needed */
   407		if (system_supports_sme()) {
   408			unsigned long sme_vl = task_get_sme_vl(current);
   409	
   410			/* Ensure VL is set up for restoring data */
   411			if (test_thread_flag(TIF_SME)) {
   412				unsigned long vq = sve_vq_from_vl(sme_vl);
   413				sysreg_clear_set_s(SYS_SMCR_EL1, SMCR_ELx_LEN, vq - 1);
   414			}
   415	
   416			write_sysreg_s(current->thread.svcr, SYS_SVCR);
   417	
   418			if (thread_za_enabled(&current->thread))
   419				sme_load_state(current->thread.sme_state,
   420					       system_supports_sme2());
   421	
   422			if (thread_sm_enabled(&current->thread))
   423				restore_ffr = system_supports_fa64();
   424		}
   425	
   426		if (system_supports_fpmr())
   427			write_sysreg_s(current->thread.uw.fpmr, SYS_FPMR);
   428	
   429		if (restore_sve_regs) {
   430			WARN_ON_ONCE(current->thread.fp_type != FP_STATE_SVE);
   431			sve_load_state(current->thread.sve_state, restore_ffr);
   432			fpsimd_load_common(&current->thread.uw.fpsimd_state);
   433		} else {
   434			WARN_ON_ONCE(current->thread.fp_type != FP_STATE_FPSIMD);
   435			fpsimd_load_state(&current->thread.uw.fpsimd_state);
   436	
   437			/*
   438			 * If the task had been using SVE we keep it enabled
   439			 * when loading FPSIMD only state for a period to
   440			 * minimise overhead for tasks actively using SVE,
   441			 * disabling it periodicaly to ensure that tasks that
   442			 * use SVE intermittently do eventually avoid the
   443			 * overhead of carrying SVE state.  The timeout is
   444			 * initialised when we take a SVE trap in do_sve_acc().
   445			 */
   446			if (system_supports_sve() && test_thread_flag(TIF_SVE)) {
   447				if (time_after(jiffies, current->thread.sve_timeout)) {
   448					clear_thread_flag(TIF_SVE);
   449					sve_user_disable();
   450				} else {
   451					/*
   452					 * Loading V will have flushed the
   453					 * rest of the Z register, SVE is
   454					 * enabled at EL1 and VL was set
   455					 * above.
   456					 */
   457					sve_flush_p();
   458				}
   459			}
   460		}
   461	}
   462	

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

                 reply	other threads:[~2026-07-01 20:44 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=202607012252.7JnbghOZ-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=broonie@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.