From: <gregkh@linuxfoundation.org>
To: nicolas.pitre@linaro.org, arnd@arndb.de,
gregkh@linuxfoundation.org, mjuszkiewicz@redhat.com,
nico@linaro.org, rmk+kernel@arm.linux.org.uk
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "ARM: 8550/1: protect idiv patching against undefined gcc behavior" has been added to the 4.5-stable tree
Date: Sun, 17 Apr 2016 03:26:30 -0700 [thread overview]
Message-ID: <146088879056117@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
ARM: 8550/1: protect idiv patching against undefined gcc behavior
to the 4.5-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:
arm-8550-1-protect-idiv-patching-against-undefined-gcc-behavior.patch
and it can be found in the queue-4.5 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 208fae5c3b9431013ad7bcea07cbcee114e7d163 Mon Sep 17 00:00:00 2001
From: Nicolas Pitre <nicolas.pitre@linaro.org>
Date: Mon, 14 Mar 2016 02:55:45 +0100
Subject: ARM: 8550/1: protect idiv patching against undefined gcc behavior
From: Nicolas Pitre <nicolas.pitre@linaro.org>
commit 208fae5c3b9431013ad7bcea07cbcee114e7d163 upstream.
It was reported that a kernel with CONFIG_ARM_PATCH_IDIV=y stopped
booting when compiled with the upcoming gcc 6. Turns out that turning
a function address into a writable array is undefined and gcc 6 decided
it was OK to omit the store to the first word of the function while
still preserving the store to the second word.
Even though gcc 6 is now fixed to behave more coherently, it is a
mystery that gcc 4 and gcc 5 actually produce wanted code in the kernel.
And in fact the reduced test case to illustrate the issue does indeed
break with gcc < 6 as well.
In any case, let's guard the kernel against undefined compiler behavior
by hiding the nature of the array location as suggested by gcc
developers.
Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70128
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Reported-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/kernel/setup.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -430,11 +430,13 @@ static void __init patch_aeabi_idiv(void
pr_info("CPU: div instructions available: patching division code\n");
fn_addr = ((uintptr_t)&__aeabi_uidiv) & ~1;
+ asm ("" : "+g" (fn_addr));
((u32 *)fn_addr)[0] = udiv_instruction();
((u32 *)fn_addr)[1] = bx_lr_instruction();
flush_icache_range(fn_addr, fn_addr + 8);
fn_addr = ((uintptr_t)&__aeabi_idiv) & ~1;
+ asm ("" : "+g" (fn_addr));
((u32 *)fn_addr)[0] = sdiv_instruction();
((u32 *)fn_addr)[1] = bx_lr_instruction();
flush_icache_range(fn_addr, fn_addr + 8);
Patches currently in stable-queue which might be from nicolas.pitre@linaro.org are
queue-4.5/arm-8550-1-protect-idiv-patching-against-undefined-gcc-behavior.patch
reply other threads:[~2016-04-17 11:01 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=146088879056117@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=mjuszkiewicz@redhat.com \
--cc=nico@linaro.org \
--cc=nicolas.pitre@linaro.org \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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.