]>
Commit | Line | Data |
---|---|---|
fcb9b3db SL |
1 | From 4e9a1c280eee932a7a100607a471f56466311eb7 Mon Sep 17 00:00:00 2001 |
2 | From: Breno Leitao <leitao@debian.org> | |
3 | Date: Mon, 8 Apr 2019 16:32:38 +1000 | |
4 | Subject: powerpc/tm: Limit TM code inside PPC_TRANSACTIONAL_MEM | |
5 | ||
6 | [ Upstream commit 897bc3df8c5aebb54c32d831f917592e873d0559 ] | |
7 | ||
8 | Commit e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint") | |
9 | moved a code block around and this block uses a 'msr' variable outside of | |
10 | the CONFIG_PPC_TRANSACTIONAL_MEM, however the 'msr' variable is declared | |
11 | inside a CONFIG_PPC_TRANSACTIONAL_MEM block, causing a possible error when | |
12 | CONFIG_PPC_TRANSACTION_MEM is not defined. | |
13 | ||
14 | error: 'msr' undeclared (first use in this function) | |
15 | ||
16 | This is not causing a compilation error in the mainline kernel, because | |
17 | 'msr' is being used as an argument of MSR_TM_ACTIVE(), which is defined as | |
18 | the following when CONFIG_PPC_TRANSACTIONAL_MEM is *not* set: | |
19 | ||
20 | #define MSR_TM_ACTIVE(x) 0 | |
21 | ||
22 | This patch just fixes this issue avoiding the 'msr' variable usage outside | |
23 | the CONFIG_PPC_TRANSACTIONAL_MEM block, avoiding trusting in the | |
24 | MSR_TM_ACTIVE() definition. | |
25 | ||
26 | Cc: stable@vger.kernel.org | |
27 | Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> | |
28 | Fixes: e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint") | |
29 | Signed-off-by: Breno Leitao <leitao@debian.org> | |
30 | Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> | |
31 | Signed-off-by: Sasha Levin <sashal@kernel.org> | |
32 | --- | |
33 | arch/powerpc/kernel/signal_64.c | 23 ++++++++++++++++++----- | |
34 | 1 file changed, 18 insertions(+), 5 deletions(-) | |
35 | ||
36 | diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c | |
37 | index 979b9463e17b..927384d85faf 100644 | |
38 | --- a/arch/powerpc/kernel/signal_64.c | |
39 | +++ b/arch/powerpc/kernel/signal_64.c | |
40 | @@ -746,12 +746,25 @@ int sys_rt_sigreturn(unsigned long r3, unsigned long r4, unsigned long r5, | |
41 | if (restore_tm_sigcontexts(current, &uc->uc_mcontext, | |
42 | &uc_transact->uc_mcontext)) | |
43 | goto badframe; | |
44 | - } | |
45 | - else | |
46 | - /* Fall through, for non-TM restore */ | |
47 | + } else | |
48 | #endif | |
49 | - if (restore_sigcontext(current, NULL, 1, &uc->uc_mcontext)) | |
50 | - goto badframe; | |
51 | + { | |
52 | + /* | |
53 | + * Fall through, for non-TM restore | |
54 | + * | |
55 | + * Unset MSR[TS] on the thread regs since MSR from user | |
56 | + * context does not have MSR active, and recheckpoint was | |
57 | + * not called since restore_tm_sigcontexts() was not called | |
58 | + * also. | |
59 | + * | |
60 | + * If not unsetting it, the code can RFID to userspace with | |
61 | + * MSR[TS] set, but without CPU in the proper state, | |
62 | + * causing a TM bad thing. | |
63 | + */ | |
64 | + current->thread.regs->msr &= ~MSR_TS_MASK; | |
65 | + if (restore_sigcontext(current, NULL, 1, &uc->uc_mcontext)) | |
66 | + goto badframe; | |
67 | + } | |
68 | ||
69 | if (restore_altstack(&uc->uc_stack)) | |
70 | goto badframe; | |
71 | -- | |
72 | 2.19.1 | |
73 |