From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, Paul Burton <paul.burton@imgtec.com>,
linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
Sasha Levin <alexander.levin@verizon.com>
Subject: [PATCH 4.4 06/50] MIPS: Ensure bss section ends on a long-aligned address
Date: Fri, 6 Oct 2017 10:52:54 +0200 [thread overview]
Message-ID: <20171006083706.190458864@linuxfoundation.org> (raw)
In-Reply-To: <20171006083705.157012217@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <paul.burton@imgtec.com>
[ Upstream commit 3f00f4d8f083bc61005d0a1ef592b149f5c88bbd ]
When clearing the .bss section in kernel_entry we do so using LONG_S
instructions, and branch whilst the current write address doesn't equal
the end of the .bss section minus the size of a long integer. The .bss
section always begins at a long-aligned address and we always increment
the write pointer by the size of a long integer - we therefore rely upon
the .bss section ending at a long-aligned address. If this is not the
case then the long-aligned write address can never be equal to the
non-long-aligned end address & we will continue to increment past the
end of the .bss section, attempting to zero the rest of memory.
Despite this requirement that .bss end at a long-aligned address we pass
0 as the end alignment requirement to the BSS_SECTION macro and thus
don't guarantee any particular alignment, allowing us to hit the error
condition described above.
Fix this by instead passing 8 bytes as the end alignment argument to
the BSS_SECTION macro, ensuring that the end of the .bss section is
always at least long-aligned.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14526/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -159,7 +159,7 @@ SECTIONS
* Force .bss to 64K alignment so that .bss..swapper_pg_dir
* gets that alignment. .sbss should be empty, so there will be
* no holes after __init_end. */
- BSS_SECTION(0, 0x10000, 0)
+ BSS_SECTION(0, 0x10000, 8)
_end = . ;
next parent reply other threads:[~2017-10-06 8:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20171006083705.157012217@linuxfoundation.org>
2017-10-06 8:52 ` Greg Kroah-Hartman [this message]
2017-10-06 8:52 ` [PATCH 4.4 07/50] MIPS: ralink: Fix incorrect assignment on ralink_soc Greg Kroah-Hartman
2017-10-06 8:53 ` [PATCH 4.4 28/50] MIPS: Lantiq: Fix another request_mem_region() return code check Greg Kroah-Hartman
2017-10-06 8:53 ` [PATCH 4.4 36/50] MIPS: IRQ Stack: Unwind IRQ stack onto task stack Greg Kroah-Hartman
2017-10-16 21:28 ` Ben Hutchings
2017-10-17 7:18 ` Matt Redfearn
2017-10-17 7:18 ` Matt Redfearn
2017-10-19 9:36 ` Greg Kroah-Hartman
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=20171006083706.190458864@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=alexander.levin@verizon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=paul.burton@imgtec.com \
--cc=ralf@linux-mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox