Patch "arm64/sve: Lower the maximum allocation for the SVE ptrace regset" has been added to the 6.1-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    arm64/sve: Lower the maximum allocation for the SVE ptrace regset

to the 6.1-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     arm64-sve-lower-the-maximum-allocation-for-the-sve-p.patch
and it can be found in the queue-6.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit b268d7c77632880430f85c53834aa517c79b027f
Author: Mark Brown <broonie@xxxxxxxxxx>
Date:   Tue Feb 13 18:24:38 2024 +0000

    arm64/sve: Lower the maximum allocation for the SVE ptrace regset
    
    [ Upstream commit 2813926261e436d33bc74486b51cce60b76edf78 ]
    
    Doug Anderson observed that ChromeOS crashes are being reported which
    include failing allocations of order 7 during core dumps due to ptrace
    allocating storage for regsets:
    
      chrome: page allocation failure: order:7,
              mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO),
              nodemask=(null),cpuset=urgent,mems_allowed=0
       ...
      regset_get_alloc+0x1c/0x28
      elf_core_dump+0x3d8/0xd8c
      do_coredump+0xeb8/0x1378
    
    with further investigation showing that this is:
    
       [   66.957385] DOUG: Allocating 279584 bytes
    
    which is the maximum size of the SVE regset. As Doug observes it is not
    entirely surprising that such a large allocation of contiguous memory might
    fail on a long running system.
    
    The SVE regset is currently sized to hold SVE registers with a VQ of
    SVE_VQ_MAX which is 512, substantially more than the architectural maximum
    of 16 which we might see even in a system emulating the limits of the
    architecture. Since we don't expose the size we tell the regset core
    externally let's define ARCH_SVE_VQ_MAX with the actual architectural
    maximum and use that for the regset, we'll still overallocate most of the
    time but much less so which will be helpful even if the core is fixed to
    not require contiguous allocations.
    
    Specify ARCH_SVE_VQ_MAX in terms of the maximum value that can be written
    into ZCR_ELx.LEN (where this is set in the hardware). For consistency
    update the maximum SME vector length to be specified in the same style
    while we are at it.
    
    We could also teach the ptrace core about runtime discoverable regset sizes
    but that would be a more invasive change and this is being observed in
    practical systems.
    
    Reported-by: Doug Anderson <dianders@xxxxxxxxxxxx>
    Signed-off-by: Mark Brown <broonie@xxxxxxxxxx>
    Tested-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
    Link: https://lore.kernel.org/r/20240213-arm64-sve-ptrace-regset-size-v2-1-c7600ca74b9b@xxxxxxxxxx
    Signed-off-by: Will Deacon <will@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index da18413712c04..930b0e6c94622 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -36,13 +36,13 @@
  * When we defined the maximum SVE vector length we defined the ABI so
  * that the maximum vector length included all the reserved for future
  * expansion bits in ZCR rather than those just currently defined by
- * the architecture. While SME follows a similar pattern the fact that
- * it includes a square matrix means that any allocations that attempt
- * to cover the maximum potential vector length (such as happen with
- * the regset used for ptrace) end up being extremely large. Define
- * the much lower actual limit for use in such situations.
+ * the architecture.  Using this length to allocate worst size buffers
+ * results in excessively large allocations, and this effect is even
+ * more pronounced for SME due to ZA.  Define more suitable VLs for
+ * these situations.
  */
-#define SME_VQ_MAX	16
+#define ARCH_SVE_VQ_MAX ((ZCR_ELx_LEN_MASK >> ZCR_ELx_LEN_SHIFT) + 1)
+#define SME_VQ_MAX	((SMCR_ELx_LEN_MASK >> SMCR_ELx_LEN_SHIFT) + 1)
 
 struct task_struct;
 
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index e1f6366b7ccdf..d02dd2be17b3b 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1450,7 +1450,8 @@ static const struct user_regset aarch64_regsets[] = {
 #ifdef CONFIG_ARM64_SVE
 	[REGSET_SVE] = { /* Scalable Vector Extension */
 		.core_note_type = NT_ARM_SVE,
-		.n = DIV_ROUND_UP(SVE_PT_SIZE(SVE_VQ_MAX, SVE_PT_REGS_SVE),
+		.n = DIV_ROUND_UP(SVE_PT_SIZE(ARCH_SVE_VQ_MAX,
+					      SVE_PT_REGS_SVE),
 				  SVE_VQ_BYTES),
 		.size = SVE_VQ_BYTES,
 		.align = SVE_VQ_BYTES,




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux