This is a note to let you know that I've just added the patch titled
sparc64: Do not define thread fpregs save area as zero-length array.
to the 3.17-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:
sparc64-do-not-define-thread-fpregs-save-area-as-zero-length-array.patch
and it can be found in the queue-3.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From foo@baz Tue Oct 28 11:21:06 CST 2014
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Sat, 18 Oct 2014 23:12:33 -0400
Subject: sparc64: Do not define thread fpregs save area as zero-length array.
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
[ Upstream commit e2653143d7d79a49f1a961aeae1d82612838b12c ]
This breaks the stack end corruption detection facility.
What that facility does it write a magic value to "end_of_stack()"
and checking to see if it gets overwritten.
"end_of_stack()" is "task_thread_info(p) + 1", which for sparc64 is
the beginning of the FPU register save area.
So once the user uses the FPU, the magic value is overwritten and the
debug checks trigger.
Fix this by making the size explicit.
Due to the size we use for the fpsaved[], gsr[], and xfsr[] arrays we
are limited to 7 levels of FPU state saves. So each FPU register set
is 256 bytes, allocate 256 * 7 for the fpregs area.
Reported-by: Meelis Roos <mroos@xxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
arch/sparc/include/asm/thread_info_64.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/sparc/include/asm/thread_info_64.h
+++ b/arch/sparc/include/asm/thread_info_64.h
@@ -63,7 +63,8 @@ struct thread_info {
struct pt_regs *kern_una_regs;
unsigned int kern_una_insn;
- unsigned long fpregs[0] __attribute__ ((aligned(64)));
+ unsigned long fpregs[(7 * 256) / sizeof(unsigned long)]
+ __attribute__ ((aligned(64)));
};
#endif /* !(__ASSEMBLY__) */
Patches currently in stable-queue which might be from davem@xxxxxxxxxxxxx are
queue-3.17/sparc64-adjust-vmalloc-region-size-based-upon-available-virtual-address-bits.patch
queue-3.17/sparc64-fix-fpu-register-corruption-with-aes-crypto-offload.patch
queue-3.17/sparc64-move-request_irq-from-ldc_bind-to-ldc_alloc.patch
queue-3.17/sparc32-dma_alloc_coherent-must-honour-gfp-flags.patch
queue-3.17/sparc64-kill-unnecessary-tables-and-increase-max_banks.patch
queue-3.17/sparc-let-memset-return-the-address-argument.patch
queue-3.17/sparc64-use-kernel-page-tables-for-vmemmap.patch
queue-3.17/sparc64-sparse-irq.patch
queue-3.17/sparc64-fix-physical-memory-management-regressions-with-large-max_phys_bits.patch
queue-3.17/sparc64-fix-lockdep-warnings-on-reboot-on-ultra-5.patch
queue-3.17/sparc64-switch-to-4-level-page-tables.patch
queue-3.17/sparc64-sun4v-tlb-error-power-off-events.patch
queue-3.17/sparc64-increase-size-of-boot-string-to-1024-bytes.patch
queue-3.17/sparc64-find_node-adjustment.patch
queue-3.17/sparc64-fix-reversed-start-end-in-flush_tlb_kernel_range.patch
queue-3.17/sparc64-increase-max_phys_address_bits-to-53.patch
queue-3.17/sparc64-define-va-hole-at-run-time-rather-than-at-compile-time.patch
queue-3.17/sparc64-fix-register-corruption-in-top-most-kernel-stack-frame-during-boot.patch
queue-3.17/sparc64-support-m6-and-m7-for-building-cpu-distribution-map.patch
queue-3.17/sparc64-cpu-hardware-caps-support-for-sparc-m6-and-m7.patch
queue-3.17/sparc64-do-not-define-thread-fpregs-save-area-as-zero-length-array.patch
queue-3.17/sparc64-t5-pmu.patch
queue-3.17/sparc64-adjust-ktsb-assembler-to-support-larger-physical-addresses.patch
queue-3.17/sparc64-implement-__get_user_pages_fast.patch
queue-3.17/sparc64-fix-corrupted-thread-fault-code.patch
queue-3.17/sparc64-fix-hibernation-code-refrence-to-page_offset.patch
queue-3.17/sparc64-correctly-recognise-m6-and-m7-cpu-type.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html