Skip to content

L
linux
Switch branch/tag
  1. 04 Aug, 2023 1 commit
    • Mark Brown's avatar
      arm64/ptrace: Don't enable SVE when setting streaming SVE · 045aecdf
      Mark Brown authored 
      Systems which implement SME without also implementing SVE are
architecturally valid but were not initially supported by the kernel,
unfortunately we missed one issue in the ptrace code.

The SVE register setting code is shared between SVE and streaming mode
SVE. When we set full SVE register state we currently enable TIF_SVE
unconditionally, in the case where streaming SVE is being configured on a
system that supports vanilla SVE this is not an issue since we always
initialise enough state for both vector lengths but on a system which only
support SME it will result in us attempting to restore the SVE vector
length after having set streaming SVE registers.

Fix this by making the enabling of SVE conditional on setting SVE vector
state. If we set streaming SVE state and SVE was not already enabled this
will result in a SVE access trap on next use of normal SVE, this will cause
us to flush our register state but this is fine since the only way to
trigger a SVE access trap would be to exit streaming mode which will cause
the in register state to be flushed anyway.

Fixes: e12310a0 ("arm64/sme: Implement ptrace support for streaming mode SVE registers")
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230803-arm64-fix-ptrace-ssve-no-sve-v1-1-49df214bfb3e@kernel.orgSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      045aecdf
  3. 03 Aug, 2023 2 commits
  5. 28 Jul, 2023 1 commit
  7. 26 Jul, 2023 2 commits
    • Mark Brown's avatar
      arm64/sme: Set new vector length before reallocating · 05d881b8
      Mark Brown authored 
      As part of fixing the allocation of the buffer for SVE state when changing
SME vector length we introduced an immediate reallocation of the SVE state,
this is also done when changing the SVE vector length for consistency.
Unfortunately this reallocation is done prior to writing the new vector
length to the task struct, meaning the allocation is done with the old
vector length and can lead to memory corruption due to an undersized buffer
being used.

Move the update of the vector length before the allocation to ensure that
the new vector length is taken into account.

For some reason this isn't triggering any problems when running tests on
the arm64 fixes branch (even after repeated tries) but is triggering
issues very often after merge into mainline.

Fixes: d4d5be94 ("arm64/fpsimd: Ensure SME storage is allocated after SVE VL changes")
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230726-arm64-fix-sme-fix-v1-1-7752ec58af27@kernel.orgSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      05d881b8
    • Mark Brown's avatar
      arm64/fpsimd: Don't flush SME register hardware state along with thread · 3421ddbe
      Mark Brown authored 
      We recently changed the fpsimd thread flush to flush the physical SME
state as well as the thread state for the current thread.  Unfortunately
this leads to intermittent corruption in interaction with the lazy
FPSIMD register switching.  When under heavy load such as can be
triggered by the startup phase of fp-stress it is possible that the
current thread may not be scheduled prior to returning to userspace, and
indeed we may end up returning to the last thread that was scheduled on
the PE without ever exiting the kernel to any other task.  If that
happens then we will not reload the register state from memory, leading
to loss of any SME register state.

Since this was purely an attempt to defensively close off potential
problems revert the change.

Fixes: af3215fd ("arm64/fpsimd: Exit streaming mode when flushing tasks")
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230724-arm64-dont-flush-smstate-v1-1-9a8b637ace6c@kernel.orgSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      3421ddbe
  9. 21 Jul, 2023 1 commit
    • Mark Brown's avatar
      arm64/fpsimd: Ensure SME storage is allocated after SVE VL changes · d4d5be94
      Mark Brown authored 
      When we reconfigure the SVE vector length we discard the backing storage
for the SVE vectors and then reallocate on next SVE use, leaving the SME
specific state alone. This means that we do not enable SME traps if they
were already disabled. That means that userspace code can enter streaming
mode without trapping, putting the task in a state where if we try to save
the state of the task we will fault.

Since the ABI does not specify that changing the SVE vector length disturbs
SME state, and since SVE code may not be aware of SME code in the process,
we shouldn't simply discard any ZA state. Instead immediately reallocate
the storage for SVE, and disable SME if we change the SVE vector length
while there is no SME state active.

Disabling SME traps on SVE vector length changes would make the overall
code more complex since we would have a state where we have valid SME state
stored but might get a SME trap.

Fixes: 9e4ab6c8 ("arm64/sme: Implement vector length configuration prctl()s")
Reported-by: default avatarDavid Spickett <David.Spickett@arm.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230720-arm64-fix-sve-sme-vl-change-v2-1-8eea06b82d57@kernel.orgSigned-off-by: default avatarWill Deacon <will@kernel.org>
      d4d5be94
  11. 20 Jul, 2023 2 commits
  13. 13 Jul, 2023 1 commit
  15. 09 Jul, 2023 10 commits
  17. 08 Jul, 2023 20 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7