From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, Matt Redfearn <matt.redfearn@imgtec.com>,
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.9 077/104] MIPS: smp-cps: Fix retrieval of VPE mask on big endian CPUs
Date: Fri, 6 Oct 2017 10:51:55 +0200 [thread overview]
Message-ID: <20171006083852.253825982@linuxfoundation.org> (raw)
In-Reply-To: <20171006083840.743659740@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Redfearn <matt.redfearn@imgtec.com>
[ Upstream commit fb2155e3c30dc2043b52020e26965067a3e7779c ]
The vpe_mask member of struct core_boot_config is of type atomic_t,
which is a 32bit type. In cps-vec.S this member was being retrieved by a
PTR_L macro, which on 64bit systems is a 64bit load. On little endian
systems this is OK, since the double word that is retrieved will have
the required less significant word in the correct position. However, on
big endian systems the less significant word of the load is retrieved
from address+4, and the more significant from address+0. The destination
register therefore ends up with the required word in the more
significant word
e.g. when starting the second VP of a big endian 64bit system, the load
PTR_L ta2, COREBOOTCFG_VPEMASK(a0)
ends up setting register ta2 to 0x0000000300000000
When this value is written to the CPC it is ignored, since it is
invalid to write anything larger than 4 bits. This results in any VP
other than VP0 in a core failing to start in 64bit big endian systems.
Change the load to a 32bit load word instruction to fix the bug.
Fixes: f12401d7219f ("MIPS: smp-cps: Pull boot config retrieval out of mips_cps_boot_vpes")
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15787/
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/cps-vec.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/kernel/cps-vec.S
+++ b/arch/mips/kernel/cps-vec.S
@@ -361,7 +361,7 @@ LEAF(mips_cps_get_bootcfg)
END(mips_cps_get_bootcfg)
LEAF(mips_cps_boot_vpes)
- PTR_L ta2, COREBOOTCFG_VPEMASK(a0)
+ lw ta2, COREBOOTCFG_VPEMASK(a0)
PTR_L ta3, COREBOOTCFG_VPECONFIG(a0)
#if defined(CONFIG_CPU_MIPSR6)
prev parent reply other threads:[~2017-10-06 8:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20171006083840.743659740@linuxfoundation.org>
2017-10-06 8:50 ` [PATCH 4.9 009/104] MIPS: Ensure bss section ends on a long-aligned address Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 010/104] MIPS: fix mem=X@Y commandline processing Greg Kroah-Hartman
2017-10-06 9:10 ` Mathieu Malaterre
2017-10-06 9:18 ` Greg Kroah-Hartman
2017-10-06 9:21 ` Mathieu Malaterre
2017-10-06 8:50 ` [PATCH 4.9 011/104] MIPS: kexec: Do not reserve invalid crashkernel memory on boot Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 012/104] MIPS: ralink: Fix a typo in the pinmux setup Greg Kroah-Hartman
2017-10-06 8:50 ` [PATCH 4.9 013/104] MIPS: ralink: Fix incorrect assignment on ralink_soc Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 055/104] MIPS: Lantiq: Fix another request_mem_region() return code check Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 056/104] mips: ath79: clock:- Unmap region obtained by of_iomap Greg Kroah-Hartman
2017-10-06 8:51 ` [PATCH 4.9 074/104] MIPS: IRQ Stack: Unwind IRQ stack onto task stack Greg Kroah-Hartman
2017-10-06 8:51 ` Greg Kroah-Hartman [this message]
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=20171006083852.253825982@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=alexander.levin@verizon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=matt.redfearn@imgtec.com \
--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