Patch "[PATCH v2 1/1] s390/signal: fix endless loop in do_signal" has been added to the 5.10-stable tree
This is a note to let you know that I've just added the patch titled
[PATCH v2 1/1] s390/signal: fix endless loop in do_signal
to the 5.10-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:
s390-signal-fix-endless-loop-in-do_signal.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From suman...@linux.ibm.com Fri Feb 17 15:04:16 2023
From: Sumanth Korikkar
Date: Wed, 15 Feb 2023 15:13:24 +0100
Subject: [PATCH v2 1/1] s390/signal: fix endless loop in do_signal
To: sta...@vger.kernel.org, gre...@linuxfoundation.org,
debian-s...@lists.debian.org, debian-kernel@lists.debian.org
Cc: sv...@linux.ibm.com, h...@linux.ibm.com, g...@linux.ibm.com,
suman...@linux.ibm.com, ulrich.weig...@de.ibm.com, dipak.zo...@ibm.com
Message-ID: <20230215141324.1239245-1-suman...@linux.ibm.com>
From: Sumanth Korikkar
No upstream commit exists: the problem addressed here is that 'commit
75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")' was backported
to 5.10. This commit is broken, but nobody noticed upstream, since
shortly after s390 converted to generic entry with 'commit 56e62a737028
("s390: convert to generic entry")', which implicitly fixed the problem
outlined below.
Thread flag is set to TIF_NOTIFY_SIGNAL for io_uring work. The io work
user or syscall calls do_signal when either one of the TIF_SIGPENDING or
TIF_NOTIFY_SIGNAL flag is set. However, do_signal does consider only
TIF_SIGPENDING signal and ignores TIF_NOTIFY_SIGNAL condition. This
means get_signal is never invoked for TIF_NOTIFY_SIGNAL and hence the
flag is not cleared, which results in an endless do_signal loop.
Reference: 'commit 788d0824269b ("io_uring: import 5.15-stable io_uring")'
Fixes: 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")
Cc: sta...@vger.kernel.org # 5.10.162
Acked-by: Heiko Carstens
Acked-by: Sven Schnelle
Signed-off-by: Sumanth Korikkar
Signed-off-by: Greg Kroah-Hartman
---
arch/s390/kernel/signal.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/s390/kernel/signal.c
+++ b/arch/s390/kernel/signal.c
@@ -472,7 +472,7 @@ void do_signal(struct pt_regs *regs)
current->thread.system_call =
test_pt_regs_flag(regs, PIF_SYSCALL) ? regs->int_code : 0;
- if (test_thread_flag(TIF_SIGPENDING) && get_signal(&ksig)) {
+ if (get_signal(&ksig)) {
/* Whee! Actually deliver the signal. */
if (current->thread.system_call) {
regs->int_code = current->thread.system_call;
Patches currently in stable-queue which might be from suman...@linux.ibm.com are
queue-5.10/s390-signal-fix-endless-loop-in-do_signal.patch
Bug#993612: Patch "of/address: Return an error when no valid dma-ranges are found" has been added to the 5.15-stable tree
This is a note to let you know that I've just added the patch titled
of/address: Return an error when no valid dma-ranges are found
to the 5.15-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:
of-address-return-an-error-when-no-valid-dma-ranges-are-found.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From f6933c01e42d2fc83b9133ed755609e4aac6eadd Mon Sep 17 00:00:00 2001
From: Mark Brown
Date: Sat, 28 Jan 2023 17:47:50 +
Subject: of/address: Return an error when no valid dma-ranges are found
From: Mark Brown
commit f6933c01e42d2fc83b9133ed755609e4aac6eadd upstream.
Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
converted the parsing of dma-range properties to use code shared with the
PCI range parser. The intent was to introduce no functional changes however
in the case where we fail to translate the first resource instead of
returning -EINVAL the new code we return 0. Restore the previous behaviour
by returning an error if we find no valid ranges, the original code only
handled the first range but subsequently support for parsing all supplied
ranges was added.
This avoids confusing code using the parsed ranges which doesn't expect to
successfully parse ranges but have only a list terminator returned, this
fixes breakage with so far as I can tell all DMA for on SoC devices on the
Socionext Synquacer platform which has a firmware supplied DT. A bisect
identified the original conversion as triggering the issues there.
Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown
Cc: Luca Di Stefano
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
Link:
https://lore.kernel.org/r/20230126-synquacer-boot-v2-1-cb80fd23c...@kernel.org
Signed-off-by: Rob Herring
Signed-off-by: Greg Kroah-Hartman
---
drivers/of/address.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -963,8 +963,19 @@ int of_dma_get_range(struct device_node
}
of_dma_range_parser_init(&parser, node);
- for_each_of_range(&parser, &range)
+ for_each_of_range(&parser, &range) {
+ if (range.cpu_addr == OF_BAD_ADDR) {
+ pr_err("translation of DMA address(%llx) to CPU address
failed node(%pOF)\n",
+ range.bus_addr, node);
+ continue;
+ }
num_ranges++;
+ }
+
+ if (!num_ranges) {
+ ret = -EINVAL;
+ goto out;
+ }
r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
if (!r) {
@@ -973,18 +984,16 @@ int of_dma_get_range(struct device_node
}
/*
-* Record all info in the generic DMA ranges array for struct device.
+* Record all info in the generic DMA ranges array for struct device,
+* returning an error if we don't find any parsable ranges.
*/
*map = r;
of_dma_range_parser_init(&parser, node);
for_each_of_range(&parser, &range) {
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
range.bus_addr, range.cpu_addr, range.size);
- if (range.cpu_addr == OF_BAD_ADDR) {
- pr_err("translation of DMA address(%llx) to CPU address
failed node(%pOF)\n",
- range.bus_addr, node);
+ if (range.cpu_addr == OF_BAD_ADDR)
continue;
- }
r->cpu_start = range.cpu_addr;
r->dma_start = range.bus_addr;
r->size = range.size;
Patches currently in stable-queue which might be from broo...@kernel.org are
queue-5.15/of-address-return-an-error-when-no-valid-dma-ranges-are-found.patch
Bug#993612: Patch "of/address: Return an error when no valid dma-ranges are found" has been added to the 5.10-stable tree
This is a note to let you know that I've just added the patch titled
of/address: Return an error when no valid dma-ranges are found
to the 5.10-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:
of-address-return-an-error-when-no-valid-dma-ranges-are-found.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From f6933c01e42d2fc83b9133ed755609e4aac6eadd Mon Sep 17 00:00:00 2001
From: Mark Brown
Date: Sat, 28 Jan 2023 17:47:50 +
Subject: of/address: Return an error when no valid dma-ranges are found
From: Mark Brown
commit f6933c01e42d2fc83b9133ed755609e4aac6eadd upstream.
Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
converted the parsing of dma-range properties to use code shared with the
PCI range parser. The intent was to introduce no functional changes however
in the case where we fail to translate the first resource instead of
returning -EINVAL the new code we return 0. Restore the previous behaviour
by returning an error if we find no valid ranges, the original code only
handled the first range but subsequently support for parsing all supplied
ranges was added.
This avoids confusing code using the parsed ranges which doesn't expect to
successfully parse ranges but have only a list terminator returned, this
fixes breakage with so far as I can tell all DMA for on SoC devices on the
Socionext Synquacer platform which has a firmware supplied DT. A bisect
identified the original conversion as triggering the issues there.
Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown
Cc: Luca Di Stefano
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
Link:
https://lore.kernel.org/r/20230126-synquacer-boot-v2-1-cb80fd23c...@kernel.org
Signed-off-by: Rob Herring
Signed-off-by: Greg Kroah-Hartman
---
drivers/of/address.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -990,8 +990,19 @@ int of_dma_get_range(struct device_node
}
of_dma_range_parser_init(&parser, node);
- for_each_of_range(&parser, &range)
+ for_each_of_range(&parser, &range) {
+ if (range.cpu_addr == OF_BAD_ADDR) {
+ pr_err("translation of DMA address(%llx) to CPU address
failed node(%pOF)\n",
+ range.bus_addr, node);
+ continue;
+ }
num_ranges++;
+ }
+
+ if (!num_ranges) {
+ ret = -EINVAL;
+ goto out;
+ }
r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
if (!r) {
@@ -1000,18 +1011,16 @@ int of_dma_get_range(struct device_node
}
/*
-* Record all info in the generic DMA ranges array for struct device.
+* Record all info in the generic DMA ranges array for struct device,
+* returning an error if we don't find any parsable ranges.
*/
*map = r;
of_dma_range_parser_init(&parser, node);
for_each_of_range(&parser, &range) {
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
range.bus_addr, range.cpu_addr, range.size);
- if (range.cpu_addr == OF_BAD_ADDR) {
- pr_err("translation of DMA address(%llx) to CPU address
failed node(%pOF)\n",
- range.bus_addr, node);
+ if (range.cpu_addr == OF_BAD_ADDR)
continue;
- }
r->cpu_start = range.cpu_addr;
r->dma_start = range.bus_addr;
r->size = range.size;
Patches currently in stable-queue which might be from broo...@kernel.org are
queue-5.10/of-address-return-an-error-when-no-valid-dma-ranges-are-found.patch
Bug#993612: Patch "of/address: Return an error when no valid dma-ranges are found" has been added to the 6.1-stable tree
This is a note to let you know that I've just added the patch titled
of/address: Return an error when no valid dma-ranges are found
to the 6.1-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:
of-address-return-an-error-when-no-valid-dma-ranges-are-found.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From f6933c01e42d2fc83b9133ed755609e4aac6eadd Mon Sep 17 00:00:00 2001
From: Mark Brown
Date: Sat, 28 Jan 2023 17:47:50 +
Subject: of/address: Return an error when no valid dma-ranges are found
From: Mark Brown
commit f6933c01e42d2fc83b9133ed755609e4aac6eadd upstream.
Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
converted the parsing of dma-range properties to use code shared with the
PCI range parser. The intent was to introduce no functional changes however
in the case where we fail to translate the first resource instead of
returning -EINVAL the new code we return 0. Restore the previous behaviour
by returning an error if we find no valid ranges, the original code only
handled the first range but subsequently support for parsing all supplied
ranges was added.
This avoids confusing code using the parsed ranges which doesn't expect to
successfully parse ranges but have only a list terminator returned, this
fixes breakage with so far as I can tell all DMA for on SoC devices on the
Socionext Synquacer platform which has a firmware supplied DT. A bisect
identified the original conversion as triggering the issues there.
Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown
Cc: Luca Di Stefano
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
Link:
https://lore.kernel.org/r/20230126-synquacer-boot-v2-1-cb80fd23c...@kernel.org
Signed-off-by: Rob Herring
Signed-off-by: Greg Kroah-Hartman
---
drivers/of/address.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -965,8 +965,19 @@ int of_dma_get_range(struct device_node
}
of_dma_range_parser_init(&parser, node);
- for_each_of_range(&parser, &range)
+ for_each_of_range(&parser, &range) {
+ if (range.cpu_addr == OF_BAD_ADDR) {
+ pr_err("translation of DMA address(%llx) to CPU address
failed node(%pOF)\n",
+ range.bus_addr, node);
+ continue;
+ }
num_ranges++;
+ }
+
+ if (!num_ranges) {
+ ret = -EINVAL;
+ goto out;
+ }
r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
if (!r) {
@@ -975,18 +986,16 @@ int of_dma_get_range(struct device_node
}
/*
-* Record all info in the generic DMA ranges array for struct device.
+* Record all info in the generic DMA ranges array for struct device,
+* returning an error if we don't find any parsable ranges.
*/
*map = r;
of_dma_range_parser_init(&parser, node);
for_each_of_range(&parser, &range) {
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
range.bus_addr, range.cpu_addr, range.size);
- if (range.cpu_addr == OF_BAD_ADDR) {
- pr_err("translation of DMA address(%llx) to CPU address
failed node(%pOF)\n",
- range.bus_addr, node);
+ if (range.cpu_addr == OF_BAD_ADDR)
continue;
- }
r->cpu_start = range.cpu_addr;
r->dma_start = range.bus_addr;
r->size = range.size;
Patches currently in stable-queue which might be from broo...@kernel.org are
queue-6.1/of-address-return-an-error-when-no-valid-dma-ranges-are-found.patch
Patch "powerpc/tm: Unset MSR[TS] if not recheckpointing" has been added to the 4.20-stable tree
This is a note to let you know that I've just added the patch titled
powerpc/tm: Unset MSR[TS] if not recheckpointing
to the 4.20-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:
powerpc-tm-unset-msr-if-not-recheckpointing.patch
and it can be found in the queue-4.20 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 6f5b9f018f4c7686fd944d920209d1382d320e4e Mon Sep 17 00:00:00 2001
From: Breno Leitao
Date: Mon, 26 Nov 2018 18:12:00 -0200
Subject: powerpc/tm: Unset MSR[TS] if not recheckpointing
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Breno Leitao
commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream.
There is a TM Bad Thing bug that can be caused when you return from a
signal context in a suspended transaction but with ucontext MSR[TS] unset.
This forces regs->msr[TS] to be set at syscall entrance (since the CPU
state is transactional). It also calls treclaim() to flush the transaction
state, which is done based on the live (mfmsr) MSR state.
Since user context MSR[TS] is not set, then restore_tm_sigcontexts() is not
called, thus, not executing recheckpoint, keeping the CPU state as not
transactional. When calling rfid, SRR1 will have MSR[TS] set, but the CPU
state is non transactional, causing the TM Bad Thing with the following
stack:
[ 33.862316] Bad kernel stack pointer 3fffd9dce3e0 at c000c47c
cpu 0x8: Vector: 700 (Program Check) at [c0003ff7fd40]
pc: c000c47c: fast_exception_return+0xac/0xb4
lr: 3fff865f442c
sp: 3fffd9dce3e0
msr: 800102a03031
current = 0xc0041f68b700
paca= 0xcfb84800 softe: 0irq_happened: 0x01
pid = 1721, comm = tm-signal-sigre
Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc
version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2
(2017-06-26)
WARNING: exception is not recoverable, can't continue
The same problem happens on 32-bits signal handler, and the fix is very
similar, if tm_recheckpoint() is not executed, then regs->msr[TS] should be
zeroed.
This patch also fixes a sparse warning related to lack of indentation when
CONFIG_PPC_TRANSACTIONAL_MEM is set.
Fixes: 2b0a576d15e0e ("powerpc: Add new transactional memory state to the
signal context")
CC: Stable # 3.10+
Signed-off-by: Breno Leitao
Tested-by: Michal Suchánek
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/signal_32.c | 18 +-
arch/powerpc/kernel/signal_64.c | 20
2 files changed, 29 insertions(+), 9 deletions(-)
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -1158,11 +1158,11 @@ SYSCALL_DEFINE0(rt_sigreturn)
{
struct rt_sigframe __user *rt_sf;
struct pt_regs *regs = current_pt_regs();
+ int tm_restore = 0;
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
struct ucontext __user *uc_transact;
unsigned long msr_hi;
unsigned long tmp;
- int tm_restore = 0;
#endif
/* Always make any pending restarted system calls return -EINTR */
current->restart_block.fn = do_no_restart_syscall;
@@ -1210,11 +1210,19 @@ SYSCALL_DEFINE0(rt_sigreturn)
goto bad;
}
}
- if (!tm_restore)
- /* Fall through, for non-TM restore */
+ if (!tm_restore) {
+ /*
+* Unset regs->msr because ucontext MSR TS is not
+* set, and recheckpoint was not called. This avoid
+* hitting a TM Bad thing at RFID
+*/
+ regs->msr &= ~MSR_TS_MASK;
+ }
+ /* Fall through, for non-TM restore */
#endif
- if (do_setcontext(&rt_sf->uc, regs, 1))
- goto bad;
+ if (!tm_restore)
+ if (do_setcontext(&rt_sf->uc, regs, 1))
+ goto bad;
/*
* It's not clear whether or why it is desirable to save the
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -756,11 +756,23 @@ SYSCALL_DEFINE0(rt_sigreturn)
&uc_transact->uc_mcontext))
goto badframe;
}
- else
- /* Fall through, for non-TM restore */
#endif
- if (restore_sigcontext(current, NULL, 1, &uc->uc_mcontext))
- goto badframe;
+ /* Fall through, for non-TM restore */
+ if (!MSR_TM_ACTIVE(msr)) {
+ /*
+* Unset MSR[TS] on the thread regs since MSR from user
+* context does not have MSR active, and recheckpoint was
+* not called since rest
Patch "powerpc/tm: Set MSR[TS] just prior to recheckpoint" has been added to the 4.20-stable tree
This is a note to let you know that I've just added the patch titled
powerpc/tm: Set MSR[TS] just prior to recheckpoint
to the 4.20-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:
powerpc-tm-set-msr-just-prior-to-recheckpoint.patch
and it can be found in the queue-4.20 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From e1c3743e1a20647c53b719dbf28b48f45d23f2cd Mon Sep 17 00:00:00 2001
From: Breno Leitao
Date: Wed, 21 Nov 2018 17:21:09 -0200
Subject: powerpc/tm: Set MSR[TS] just prior to recheckpoint
From: Breno Leitao
commit e1c3743e1a20647c53b719dbf28b48f45d23f2cd upstream.
On a signal handler return, the user could set a context with MSR[TS] bits
set, and these bits would be copied to task regs->msr.
At restore_tm_sigcontexts(), after current task regs->msr[TS] bits are set,
several __get_user() are called and then a recheckpoint is executed.
This is a problem since a page fault (in kernel space) could happen when
calling __get_user(). If it happens, the process MSR[TS] bits were
already set, but recheckpoint was not executed, and SPRs are still invalid.
The page fault can cause the current process to be de-scheduled, with
MSR[TS] active and without tm_recheckpoint() being called. More
importantly, without TEXASR[FS] bit set also.
Since TEXASR might not have the FS bit set, and when the process is
scheduled back, it will try to reclaim, which will be aborted because of
the CPU is not in the suspended state, and, then, recheckpoint. This
recheckpoint will restore thread->texasr into TEXASR SPR, which might be
zero, hitting a BUG_ON().
kernel BUG at
/build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
cpu 0xb: Vector: 700 (Program Check) at [c0041f1576d0]
pc: c0054550: restore_gprs+0xb0/0x180
lr:
sp: c0041f157950
msr: 800100021033
current = 0xc0041f143000
paca= 0xcfb86300 softe: 0irq_happened: 0x01
pid = 1021, comm = kworker/11:1
kernel BUG at
/build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc
version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2
(2017-06-26)
enter ? for help
[c0041f157b30] c001bc3c tm_recheckpoint.part.11+0x6c/0xa0
[c0041f157b70] c001d184 __switch_to+0x1e4/0x4c0
[c0041f157bd0] c082eeb8 __schedule+0x2f8/0x990
[c0041f157cb0] c082f598 schedule+0x48/0xc0
[c0041f157ce0] c00f0d28 worker_thread+0x148/0x610
[c0041f157d80] c00f96b0 kthread+0x120/0x140
[c0041f157e30] c000c0e0 ret_from_kernel_thread+0x5c/0x7c
This patch simply delays the MSR[TS] set, so, if there is any page fault in
the __get_user() section, it does not have regs->msr[TS] set, since the TM
structures are still invalid, thus avoiding doing TM operations for
in-kernel exceptions and possible process reschedule.
With this patch, the MSR[TS] will only be set just before recheckpointing
and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in
invalid state.
Other than that, if CONFIG_PREEMPT is set, there might be a preemption just
after setting MSR[TS] and before tm_recheckpoint(), thus, this block must
be atomic from a preemption perspective, thus, calling
preempt_disable/enable() on this code.
It is not possible to move tm_recheckpoint to happen earlier, because it is
required to get the checkpointed registers from userspace, with
__get_user(), thus, the only way to avoid this undesired behavior is
delaying the MSR[TS] set.
The 32-bits signal handler seems to be safe this current issue, but, it
might be exposed to the preemption issue, thus, disabling preemption in
this chunk of code.
Changes from v2:
* Run the critical section with preempt_disable.
Fixes: 87b4e5393af7 ("powerpc/tm: Fix return of active 64bit signals")
Cc: sta...@vger.kernel.org (v3.9+)
Signed-off-by: Breno Leitao
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/signal_32.c | 20 +-
arch/powerpc/kernel/signal_64.c | 44 +++-
2 files changed, 49 insertions(+), 15 deletions(-)
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -848,7 +848,23 @@ static long restore_tm_user_regs(struct
/* If TM bits are set to the reserved value, it's an invalid context */
if (MSR_TM_RESV(msr_hi))
return 1;
- /* Pull in the MSR TM bits from the user context */
+
+ /*
+* Disabling preemption, since it is unsafe to be preempted
+* with MSR[TS] set w
Patch "powerpc/tm: Set MSR[TS] just prior to recheckpoint" has been added to the 4.14-stable tree
This is a note to let you know that I've just added the patch titled
powerpc/tm: Set MSR[TS] just prior to recheckpoint
to the 4.14-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:
powerpc-tm-set-msr-just-prior-to-recheckpoint.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From e1c3743e1a20647c53b719dbf28b48f45d23f2cd Mon Sep 17 00:00:00 2001
From: Breno Leitao
Date: Wed, 21 Nov 2018 17:21:09 -0200
Subject: powerpc/tm: Set MSR[TS] just prior to recheckpoint
From: Breno Leitao
commit e1c3743e1a20647c53b719dbf28b48f45d23f2cd upstream.
On a signal handler return, the user could set a context with MSR[TS] bits
set, and these bits would be copied to task regs->msr.
At restore_tm_sigcontexts(), after current task regs->msr[TS] bits are set,
several __get_user() are called and then a recheckpoint is executed.
This is a problem since a page fault (in kernel space) could happen when
calling __get_user(). If it happens, the process MSR[TS] bits were
already set, but recheckpoint was not executed, and SPRs are still invalid.
The page fault can cause the current process to be de-scheduled, with
MSR[TS] active and without tm_recheckpoint() being called. More
importantly, without TEXASR[FS] bit set also.
Since TEXASR might not have the FS bit set, and when the process is
scheduled back, it will try to reclaim, which will be aborted because of
the CPU is not in the suspended state, and, then, recheckpoint. This
recheckpoint will restore thread->texasr into TEXASR SPR, which might be
zero, hitting a BUG_ON().
kernel BUG at
/build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
cpu 0xb: Vector: 700 (Program Check) at [c0041f1576d0]
pc: c0054550: restore_gprs+0xb0/0x180
lr:
sp: c0041f157950
msr: 800100021033
current = 0xc0041f143000
paca= 0xcfb86300 softe: 0irq_happened: 0x01
pid = 1021, comm = kworker/11:1
kernel BUG at
/build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc
version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2
(2017-06-26)
enter ? for help
[c0041f157b30] c001bc3c tm_recheckpoint.part.11+0x6c/0xa0
[c0041f157b70] c001d184 __switch_to+0x1e4/0x4c0
[c0041f157bd0] c082eeb8 __schedule+0x2f8/0x990
[c0041f157cb0] c082f598 schedule+0x48/0xc0
[c0041f157ce0] c00f0d28 worker_thread+0x148/0x610
[c0041f157d80] c00f96b0 kthread+0x120/0x140
[c0041f157e30] c000c0e0 ret_from_kernel_thread+0x5c/0x7c
This patch simply delays the MSR[TS] set, so, if there is any page fault in
the __get_user() section, it does not have regs->msr[TS] set, since the TM
structures are still invalid, thus avoiding doing TM operations for
in-kernel exceptions and possible process reschedule.
With this patch, the MSR[TS] will only be set just before recheckpointing
and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in
invalid state.
Other than that, if CONFIG_PREEMPT is set, there might be a preemption just
after setting MSR[TS] and before tm_recheckpoint(), thus, this block must
be atomic from a preemption perspective, thus, calling
preempt_disable/enable() on this code.
It is not possible to move tm_recheckpoint to happen earlier, because it is
required to get the checkpointed registers from userspace, with
__get_user(), thus, the only way to avoid this undesired behavior is
delaying the MSR[TS] set.
The 32-bits signal handler seems to be safe this current issue, but, it
might be exposed to the preemption issue, thus, disabling preemption in
this chunk of code.
Changes from v2:
* Run the critical section with preempt_disable.
Fixes: 87b4e5393af7 ("powerpc/tm: Fix return of active 64bit signals")
Cc: sta...@vger.kernel.org (v3.9+)
Signed-off-by: Breno Leitao
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/signal_32.c | 20 +-
arch/powerpc/kernel/signal_64.c | 44 +++-
2 files changed, 49 insertions(+), 15 deletions(-)
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -866,7 +866,23 @@ static long restore_tm_user_regs(struct
/* If TM bits are set to the reserved value, it's an invalid context */
if (MSR_TM_RESV(msr_hi))
return 1;
- /* Pull in the MSR TM bits from the user context */
+
+ /*
+* Disabling preemption, since it is unsafe to be preempted
+* with MSR[TS] set w
Patch "powerpc/tm: Set MSR[TS] just prior to recheckpoint" has been added to the 4.9-stable tree
This is a note to let you know that I've just added the patch titled
powerpc/tm: Set MSR[TS] just prior to recheckpoint
to the 4.9-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:
powerpc-tm-set-msr-just-prior-to-recheckpoint.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From e1c3743e1a20647c53b719dbf28b48f45d23f2cd Mon Sep 17 00:00:00 2001
From: Breno Leitao
Date: Wed, 21 Nov 2018 17:21:09 -0200
Subject: powerpc/tm: Set MSR[TS] just prior to recheckpoint
From: Breno Leitao
commit e1c3743e1a20647c53b719dbf28b48f45d23f2cd upstream.
On a signal handler return, the user could set a context with MSR[TS] bits
set, and these bits would be copied to task regs->msr.
At restore_tm_sigcontexts(), after current task regs->msr[TS] bits are set,
several __get_user() are called and then a recheckpoint is executed.
This is a problem since a page fault (in kernel space) could happen when
calling __get_user(). If it happens, the process MSR[TS] bits were
already set, but recheckpoint was not executed, and SPRs are still invalid.
The page fault can cause the current process to be de-scheduled, with
MSR[TS] active and without tm_recheckpoint() being called. More
importantly, without TEXASR[FS] bit set also.
Since TEXASR might not have the FS bit set, and when the process is
scheduled back, it will try to reclaim, which will be aborted because of
the CPU is not in the suspended state, and, then, recheckpoint. This
recheckpoint will restore thread->texasr into TEXASR SPR, which might be
zero, hitting a BUG_ON().
kernel BUG at
/build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
cpu 0xb: Vector: 700 (Program Check) at [c0041f1576d0]
pc: c0054550: restore_gprs+0xb0/0x180
lr:
sp: c0041f157950
msr: 800100021033
current = 0xc0041f143000
paca= 0xcfb86300 softe: 0irq_happened: 0x01
pid = 1021, comm = kworker/11:1
kernel BUG at
/build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc
version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2
(2017-06-26)
enter ? for help
[c0041f157b30] c001bc3c tm_recheckpoint.part.11+0x6c/0xa0
[c0041f157b70] c001d184 __switch_to+0x1e4/0x4c0
[c0041f157bd0] c082eeb8 __schedule+0x2f8/0x990
[c0041f157cb0] c082f598 schedule+0x48/0xc0
[c0041f157ce0] c00f0d28 worker_thread+0x148/0x610
[c0041f157d80] c00f96b0 kthread+0x120/0x140
[c0041f157e30] c000c0e0 ret_from_kernel_thread+0x5c/0x7c
This patch simply delays the MSR[TS] set, so, if there is any page fault in
the __get_user() section, it does not have regs->msr[TS] set, since the TM
structures are still invalid, thus avoiding doing TM operations for
in-kernel exceptions and possible process reschedule.
With this patch, the MSR[TS] will only be set just before recheckpointing
and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in
invalid state.
Other than that, if CONFIG_PREEMPT is set, there might be a preemption just
after setting MSR[TS] and before tm_recheckpoint(), thus, this block must
be atomic from a preemption perspective, thus, calling
preempt_disable/enable() on this code.
It is not possible to move tm_recheckpoint to happen earlier, because it is
required to get the checkpointed registers from userspace, with
__get_user(), thus, the only way to avoid this undesired behavior is
delaying the MSR[TS] set.
The 32-bits signal handler seems to be safe this current issue, but, it
might be exposed to the preemption issue, thus, disabling preemption in
this chunk of code.
Changes from v2:
* Run the critical section with preempt_disable.
Fixes: 87b4e5393af7 ("powerpc/tm: Fix return of active 64bit signals")
Cc: sta...@vger.kernel.org (v3.9+)
Signed-off-by: Breno Leitao
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/signal_32.c | 20 +-
arch/powerpc/kernel/signal_64.c | 44 +++-
2 files changed, 49 insertions(+), 15 deletions(-)
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -866,7 +866,23 @@ static long restore_tm_user_regs(struct
/* If TM bits are set to the reserved value, it's an invalid context */
if (MSR_TM_RESV(msr_hi))
return 1;
- /* Pull in the MSR TM bits from the user context */
+
+ /*
+* Disabling preemption, since it is unsafe to be preempted
+* with MSR[TS] set wit
Patch "powerpc/tm: Set MSR[TS] just prior to recheckpoint" has been added to the 4.19-stable tree
This is a note to let you know that I've just added the patch titled
powerpc/tm: Set MSR[TS] just prior to recheckpoint
to the 4.19-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:
powerpc-tm-set-msr-just-prior-to-recheckpoint.patch
and it can be found in the queue-4.19 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From e1c3743e1a20647c53b719dbf28b48f45d23f2cd Mon Sep 17 00:00:00 2001
From: Breno Leitao
Date: Wed, 21 Nov 2018 17:21:09 -0200
Subject: powerpc/tm: Set MSR[TS] just prior to recheckpoint
From: Breno Leitao
commit e1c3743e1a20647c53b719dbf28b48f45d23f2cd upstream.
On a signal handler return, the user could set a context with MSR[TS] bits
set, and these bits would be copied to task regs->msr.
At restore_tm_sigcontexts(), after current task regs->msr[TS] bits are set,
several __get_user() are called and then a recheckpoint is executed.
This is a problem since a page fault (in kernel space) could happen when
calling __get_user(). If it happens, the process MSR[TS] bits were
already set, but recheckpoint was not executed, and SPRs are still invalid.
The page fault can cause the current process to be de-scheduled, with
MSR[TS] active and without tm_recheckpoint() being called. More
importantly, without TEXASR[FS] bit set also.
Since TEXASR might not have the FS bit set, and when the process is
scheduled back, it will try to reclaim, which will be aborted because of
the CPU is not in the suspended state, and, then, recheckpoint. This
recheckpoint will restore thread->texasr into TEXASR SPR, which might be
zero, hitting a BUG_ON().
kernel BUG at
/build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
cpu 0xb: Vector: 700 (Program Check) at [c0041f1576d0]
pc: c0054550: restore_gprs+0xb0/0x180
lr:
sp: c0041f157950
msr: 800100021033
current = 0xc0041f143000
paca= 0xcfb86300 softe: 0irq_happened: 0x01
pid = 1021, comm = kworker/11:1
kernel BUG at
/build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc
version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2
(2017-06-26)
enter ? for help
[c0041f157b30] c001bc3c tm_recheckpoint.part.11+0x6c/0xa0
[c0041f157b70] c001d184 __switch_to+0x1e4/0x4c0
[c0041f157bd0] c082eeb8 __schedule+0x2f8/0x990
[c0041f157cb0] c082f598 schedule+0x48/0xc0
[c0041f157ce0] c00f0d28 worker_thread+0x148/0x610
[c0041f157d80] c00f96b0 kthread+0x120/0x140
[c0041f157e30] c000c0e0 ret_from_kernel_thread+0x5c/0x7c
This patch simply delays the MSR[TS] set, so, if there is any page fault in
the __get_user() section, it does not have regs->msr[TS] set, since the TM
structures are still invalid, thus avoiding doing TM operations for
in-kernel exceptions and possible process reschedule.
With this patch, the MSR[TS] will only be set just before recheckpointing
and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in
invalid state.
Other than that, if CONFIG_PREEMPT is set, there might be a preemption just
after setting MSR[TS] and before tm_recheckpoint(), thus, this block must
be atomic from a preemption perspective, thus, calling
preempt_disable/enable() on this code.
It is not possible to move tm_recheckpoint to happen earlier, because it is
required to get the checkpointed registers from userspace, with
__get_user(), thus, the only way to avoid this undesired behavior is
delaying the MSR[TS] set.
The 32-bits signal handler seems to be safe this current issue, but, it
might be exposed to the preemption issue, thus, disabling preemption in
this chunk of code.
Changes from v2:
* Run the critical section with preempt_disable.
Fixes: 87b4e5393af7 ("powerpc/tm: Fix return of active 64bit signals")
Cc: sta...@vger.kernel.org (v3.9+)
Signed-off-by: Breno Leitao
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/signal_32.c | 20 +-
arch/powerpc/kernel/signal_64.c | 44 +++-
2 files changed, 49 insertions(+), 15 deletions(-)
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -848,7 +848,23 @@ static long restore_tm_user_regs(struct
/* If TM bits are set to the reserved value, it's an invalid context */
if (MSR_TM_RESV(msr_hi))
return 1;
- /* Pull in the MSR TM bits from the user context */
+
+ /*
+* Disabling preemption, since it is unsafe to be preempted
+* with MSR[TS] set w
Patch "powerpc/tm: Unset MSR[TS] if not recheckpointing" has been added to the 4.19-stable tree
This is a note to let you know that I've just added the patch titled
powerpc/tm: Unset MSR[TS] if not recheckpointing
to the 4.19-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:
powerpc-tm-unset-msr-if-not-recheckpointing.patch
and it can be found in the queue-4.19 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 6f5b9f018f4c7686fd944d920209d1382d320e4e Mon Sep 17 00:00:00 2001
From: Breno Leitao
Date: Mon, 26 Nov 2018 18:12:00 -0200
Subject: powerpc/tm: Unset MSR[TS] if not recheckpointing
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Breno Leitao
commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream.
There is a TM Bad Thing bug that can be caused when you return from a
signal context in a suspended transaction but with ucontext MSR[TS] unset.
This forces regs->msr[TS] to be set at syscall entrance (since the CPU
state is transactional). It also calls treclaim() to flush the transaction
state, which is done based on the live (mfmsr) MSR state.
Since user context MSR[TS] is not set, then restore_tm_sigcontexts() is not
called, thus, not executing recheckpoint, keeping the CPU state as not
transactional. When calling rfid, SRR1 will have MSR[TS] set, but the CPU
state is non transactional, causing the TM Bad Thing with the following
stack:
[ 33.862316] Bad kernel stack pointer 3fffd9dce3e0 at c000c47c
cpu 0x8: Vector: 700 (Program Check) at [c0003ff7fd40]
pc: c000c47c: fast_exception_return+0xac/0xb4
lr: 3fff865f442c
sp: 3fffd9dce3e0
msr: 800102a03031
current = 0xc0041f68b700
paca= 0xcfb84800 softe: 0irq_happened: 0x01
pid = 1721, comm = tm-signal-sigre
Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc
version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2
(2017-06-26)
WARNING: exception is not recoverable, can't continue
The same problem happens on 32-bits signal handler, and the fix is very
similar, if tm_recheckpoint() is not executed, then regs->msr[TS] should be
zeroed.
This patch also fixes a sparse warning related to lack of indentation when
CONFIG_PPC_TRANSACTIONAL_MEM is set.
Fixes: 2b0a576d15e0e ("powerpc: Add new transactional memory state to the
signal context")
CC: Stable # 3.10+
Signed-off-by: Breno Leitao
Tested-by: Michal Suchánek
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/signal_32.c | 18 +-
arch/powerpc/kernel/signal_64.c | 20
2 files changed, 29 insertions(+), 9 deletions(-)
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -1158,11 +1158,11 @@ SYSCALL_DEFINE0(rt_sigreturn)
{
struct rt_sigframe __user *rt_sf;
struct pt_regs *regs = current_pt_regs();
+ int tm_restore = 0;
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
struct ucontext __user *uc_transact;
unsigned long msr_hi;
unsigned long tmp;
- int tm_restore = 0;
#endif
/* Always make any pending restarted system calls return -EINTR */
current->restart_block.fn = do_no_restart_syscall;
@@ -1210,11 +1210,19 @@ SYSCALL_DEFINE0(rt_sigreturn)
goto bad;
}
}
- if (!tm_restore)
- /* Fall through, for non-TM restore */
+ if (!tm_restore) {
+ /*
+* Unset regs->msr because ucontext MSR TS is not
+* set, and recheckpoint was not called. This avoid
+* hitting a TM Bad thing at RFID
+*/
+ regs->msr &= ~MSR_TS_MASK;
+ }
+ /* Fall through, for non-TM restore */
#endif
- if (do_setcontext(&rt_sf->uc, regs, 1))
- goto bad;
+ if (!tm_restore)
+ if (do_setcontext(&rt_sf->uc, regs, 1))
+ goto bad;
/*
* It's not clear whether or why it is desirable to save the
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -756,11 +756,23 @@ SYSCALL_DEFINE0(rt_sigreturn)
&uc_transact->uc_mcontext))
goto badframe;
}
- else
- /* Fall through, for non-TM restore */
#endif
- if (restore_sigcontext(current, NULL, 1, &uc->uc_mcontext))
- goto badframe;
+ /* Fall through, for non-TM restore */
+ if (!MSR_TM_ACTIVE(msr)) {
+ /*
+* Unset MSR[TS] on the thread regs since MSR from user
+* context does not have MSR active, and recheckpoint was
+* not called since rest
Patch "powerpc/tm: Set MSR[TS] just prior to recheckpoint" has been added to the 4.19-stable tree
This is a note to let you know that I've just added the patch titled
powerpc/tm: Set MSR[TS] just prior to recheckpoint
to the 4.19-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:
powerpc-tm-set-msr-just-prior-to-recheckpoint.patch
and it can be found in the queue-4.19 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From e1c3743e1a20647c53b719dbf28b48f45d23f2cd Mon Sep 17 00:00:00 2001
From: Breno Leitao
Date: Wed, 21 Nov 2018 17:21:09 -0200
Subject: powerpc/tm: Set MSR[TS] just prior to recheckpoint
From: Breno Leitao
commit e1c3743e1a20647c53b719dbf28b48f45d23f2cd upstream.
On a signal handler return, the user could set a context with MSR[TS] bits
set, and these bits would be copied to task regs->msr.
At restore_tm_sigcontexts(), after current task regs->msr[TS] bits are set,
several __get_user() are called and then a recheckpoint is executed.
This is a problem since a page fault (in kernel space) could happen when
calling __get_user(). If it happens, the process MSR[TS] bits were
already set, but recheckpoint was not executed, and SPRs are still invalid.
The page fault can cause the current process to be de-scheduled, with
MSR[TS] active and without tm_recheckpoint() being called. More
importantly, without TEXASR[FS] bit set also.
Since TEXASR might not have the FS bit set, and when the process is
scheduled back, it will try to reclaim, which will be aborted because of
the CPU is not in the suspended state, and, then, recheckpoint. This
recheckpoint will restore thread->texasr into TEXASR SPR, which might be
zero, hitting a BUG_ON().
kernel BUG at
/build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
cpu 0xb: Vector: 700 (Program Check) at [c0041f1576d0]
pc: c0054550: restore_gprs+0xb0/0x180
lr:
sp: c0041f157950
msr: 800100021033
current = 0xc0041f143000
paca= 0xcfb86300 softe: 0irq_happened: 0x01
pid = 1021, comm = kworker/11:1
kernel BUG at
/build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc
version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2
(2017-06-26)
enter ? for help
[c0041f157b30] c001bc3c tm_recheckpoint.part.11+0x6c/0xa0
[c0041f157b70] c001d184 __switch_to+0x1e4/0x4c0
[c0041f157bd0] c082eeb8 __schedule+0x2f8/0x990
[c0041f157cb0] c082f598 schedule+0x48/0xc0
[c0041f157ce0] c00f0d28 worker_thread+0x148/0x610
[c0041f157d80] c00f96b0 kthread+0x120/0x140
[c0041f157e30] c000c0e0 ret_from_kernel_thread+0x5c/0x7c
This patch simply delays the MSR[TS] set, so, if there is any page fault in
the __get_user() section, it does not have regs->msr[TS] set, since the TM
structures are still invalid, thus avoiding doing TM operations for
in-kernel exceptions and possible process reschedule.
With this patch, the MSR[TS] will only be set just before recheckpointing
and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in
invalid state.
Other than that, if CONFIG_PREEMPT is set, there might be a preemption just
after setting MSR[TS] and before tm_recheckpoint(), thus, this block must
be atomic from a preemption perspective, thus, calling
preempt_disable/enable() on this code.
It is not possible to move tm_recheckpoint to happen earlier, because it is
required to get the checkpointed registers from userspace, with
__get_user(), thus, the only way to avoid this undesired behavior is
delaying the MSR[TS] set.
The 32-bits signal handler seems to be safe this current issue, but, it
might be exposed to the preemption issue, thus, disabling preemption in
this chunk of code.
Changes from v2:
* Run the critical section with preempt_disable.
Fixes: 87b4e5393af7 ("powerpc/tm: Fix return of active 64bit signals")
Cc: sta...@vger.kernel.org (v3.9+)
Signed-off-by: Breno Leitao
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/signal_32.c | 20 +-
arch/powerpc/kernel/signal_64.c | 44 +++-
2 files changed, 49 insertions(+), 15 deletions(-)
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -848,7 +848,23 @@ static long restore_tm_user_regs(struct
/* If TM bits are set to the reserved value, it's an invalid context */
if (MSR_TM_RESV(msr_hi))
return 1;
- /* Pull in the MSR TM bits from the user context */
+
+ /*
+* Disabling preemption, since it is unsafe to be preempted
+* with MSR[TS] set w
Patch "powerpc/tm: Set MSR[TS] just prior to recheckpoint" has been added to the 4.14-stable tree
This is a note to let you know that I've just added the patch titled
powerpc/tm: Set MSR[TS] just prior to recheckpoint
to the 4.14-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:
powerpc-tm-set-msr-just-prior-to-recheckpoint.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From e1c3743e1a20647c53b719dbf28b48f45d23f2cd Mon Sep 17 00:00:00 2001
From: Breno Leitao
Date: Wed, 21 Nov 2018 17:21:09 -0200
Subject: powerpc/tm: Set MSR[TS] just prior to recheckpoint
From: Breno Leitao
commit e1c3743e1a20647c53b719dbf28b48f45d23f2cd upstream.
On a signal handler return, the user could set a context with MSR[TS] bits
set, and these bits would be copied to task regs->msr.
At restore_tm_sigcontexts(), after current task regs->msr[TS] bits are set,
several __get_user() are called and then a recheckpoint is executed.
This is a problem since a page fault (in kernel space) could happen when
calling __get_user(). If it happens, the process MSR[TS] bits were
already set, but recheckpoint was not executed, and SPRs are still invalid.
The page fault can cause the current process to be de-scheduled, with
MSR[TS] active and without tm_recheckpoint() being called. More
importantly, without TEXASR[FS] bit set also.
Since TEXASR might not have the FS bit set, and when the process is
scheduled back, it will try to reclaim, which will be aborted because of
the CPU is not in the suspended state, and, then, recheckpoint. This
recheckpoint will restore thread->texasr into TEXASR SPR, which might be
zero, hitting a BUG_ON().
kernel BUG at
/build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
cpu 0xb: Vector: 700 (Program Check) at [c0041f1576d0]
pc: c0054550: restore_gprs+0xb0/0x180
lr:
sp: c0041f157950
msr: 800100021033
current = 0xc0041f143000
paca= 0xcfb86300 softe: 0irq_happened: 0x01
pid = 1021, comm = kworker/11:1
kernel BUG at
/build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc
version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2
(2017-06-26)
enter ? for help
[c0041f157b30] c001bc3c tm_recheckpoint.part.11+0x6c/0xa0
[c0041f157b70] c001d184 __switch_to+0x1e4/0x4c0
[c0041f157bd0] c082eeb8 __schedule+0x2f8/0x990
[c0041f157cb0] c082f598 schedule+0x48/0xc0
[c0041f157ce0] c00f0d28 worker_thread+0x148/0x610
[c0041f157d80] c00f96b0 kthread+0x120/0x140
[c0041f157e30] c000c0e0 ret_from_kernel_thread+0x5c/0x7c
This patch simply delays the MSR[TS] set, so, if there is any page fault in
the __get_user() section, it does not have regs->msr[TS] set, since the TM
structures are still invalid, thus avoiding doing TM operations for
in-kernel exceptions and possible process reschedule.
With this patch, the MSR[TS] will only be set just before recheckpointing
and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in
invalid state.
Other than that, if CONFIG_PREEMPT is set, there might be a preemption just
after setting MSR[TS] and before tm_recheckpoint(), thus, this block must
be atomic from a preemption perspective, thus, calling
preempt_disable/enable() on this code.
It is not possible to move tm_recheckpoint to happen earlier, because it is
required to get the checkpointed registers from userspace, with
__get_user(), thus, the only way to avoid this undesired behavior is
delaying the MSR[TS] set.
The 32-bits signal handler seems to be safe this current issue, but, it
might be exposed to the preemption issue, thus, disabling preemption in
this chunk of code.
Changes from v2:
* Run the critical section with preempt_disable.
Fixes: 87b4e5393af7 ("powerpc/tm: Fix return of active 64bit signals")
Cc: sta...@vger.kernel.org (v3.9+)
Signed-off-by: Breno Leitao
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/signal_32.c | 20 +-
arch/powerpc/kernel/signal_64.c | 44 +++-
2 files changed, 49 insertions(+), 15 deletions(-)
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -866,7 +866,23 @@ static long restore_tm_user_regs(struct
/* If TM bits are set to the reserved value, it's an invalid context */
if (MSR_TM_RESV(msr_hi))
return 1;
- /* Pull in the MSR TM bits from the user context */
+
+ /*
+* Disabling preemption, since it is unsafe to be preempted
+* with MSR[TS] set w
Patch "irq: Always define devm_{request_threaded,free}_irq()" has been added to the 3.11-stable tree
This is a note to let you know that I've just added the patch titled
irq: Always define devm_{request_threaded,free}_irq()
to the 3.11-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:
irq-always-define-devm_-request_threaded-free-_irq.patch
and it can be found in the queue-3.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From b...@decadent.org.uk Wed Oct 2 19:49:05 2013
From: Ben Hutchings
Date: Mon, 30 Sep 2013 00:53:31 +0100
Subject: irq: Always define devm_{request_threaded,free}_irq()
To: sta...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org, Debian kernel maintainers
, linux-s...@vger.kernel.org, Thomas Gleixner
Message-ID: <1380498811.14493.7.ca...@deadeye.wl.decadent.org.uk>
From: Ben Hutchings
This is only needed for 3.11, as s390 has now been changed to use the
generic IRQ code upstream.
These functions are currently defined only if CONFIG_GENERIC_HARDIRQS
is enabled. But they are still needed on s390 which has its own IRQ
management.
References:
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=s390&ver=3.11%7Erc4-1%7Eexp1&stamp=1376009959
Signed-off-by: Ben Hutchings
---
kernel/Makefile |2 +-
kernel/irq/Makefile |6 --
2 files changed, 5 insertions(+), 3 deletions(-)
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -79,7 +79,7 @@ obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_KGDB) += debug/
obj-$(CONFIG_DETECT_HUNG_TASK) += hung_task.o
obj-$(CONFIG_LOCKUP_DETECTOR) += watchdog.o
-obj-$(CONFIG_GENERIC_HARDIRQS) += irq/
+obj-y += irq/
obj-$(CONFIG_SECCOMP) += seccomp.o
obj-$(CONFIG_RCU_TORTURE_TEST) += rcutorture.o
obj-$(CONFIG_TREE_RCU) += rcutree.o
--- a/kernel/irq/Makefile
+++ b/kernel/irq/Makefile
@@ -1,8 +1,10 @@
-
-obj-y := irqdesc.o handle.o manage.o spurious.o resend.o chip.o dummychip.o
devres.o
+obj-y += devres.o
+ifdef CONFIG_GENERIC_HARDIRQS
+obj-y += irqdesc.o handle.o manage.o spurious.o resend.o chip.o dummychip.o
obj-$(CONFIG_GENERIC_IRQ_CHIP) += generic-chip.o
obj-$(CONFIG_GENERIC_IRQ_PROBE) += autoprobe.o
obj-$(CONFIG_IRQ_DOMAIN) += irqdomain.o
obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_GENERIC_PENDING_IRQ) += migration.o
obj-$(CONFIG_PM_SLEEP) += pm.o
+endif
Patches currently in stable-queue which might be from b...@decadent.org.uk are
queue-3.11/irq-always-define-devm_-request_threaded-free-_irq.patch
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/13807686843...@kroah.org
Patch "s390: Add pgste to ptep_modify_prot_start()" has been added to the 3.9-stable tree
This is a note to let you know that I've just added the patch titled
s390: Add pgste to ptep_modify_prot_start()
to the 3.9-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:
s390-add-pgste-to-ptep_modify_prot_start.patch
and it can be found in the queue-3.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From b...@decadent.org.uk Mon Jun 10 14:39:38 2013
From: Ben Hutchings
Date: Sun, 09 Jun 2013 21:09:24 +0100
Subject: s390: Add pgste to ptep_modify_prot_start()
To: Greg Kroah-Hartman
Cc: sta...@vger.kernel.org, linux-s...@vger.kernel.org, Debian kernel
maintainers
Message-ID: <1370808564.5614.14.ca...@deadeye.wl.decadent.org.uk>
From: Ben Hutchings
Commit 52f36be0f4e2 's390/pgtable: Fix check for pgste/storage key
handling', which was commit b56433cb782d upstream, added a use of
pgste to ptep_modify_prot_start(), but this variable does not exist.
In mainline, pgste was added by commit d3383632d4e8 's390/mm: add pte
invalidation notifier for kvm' and initialised to the return value of
pgste_get_lock(ptep). Initialise it similarly here.
Compile-tested only.
Signed-off-by: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman
---
arch/s390/include/asm/pgtable.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1063,11 +1063,12 @@ static inline pte_t ptep_modify_prot_sta
unsigned long address,
pte_t *ptep)
{
+ pgste_t pgste;
pte_t pte;
mm->context.flush_mm = 1;
if (mm_has_pgste(mm))
- pgste_get_lock(ptep);
+ pgste = pgste_get_lock(ptep);
pte = *ptep;
if (!mm_exclusive(mm))
Patches currently in stable-queue which might be from b...@decadent.org.uk are
queue-3.9/s390-add-pgste-to-ptep_modify_prot_start.patch
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/13709004541...@kroah.org
Patch "lockdep, bug: Exclude TAINT_OOT_MODULE from disabling lock debugging" has been added to the 3.2-stable tree
This is a note to let you know that I've just added the patch titled
lockdep, bug: Exclude TAINT_OOT_MODULE from disabling lock debugging
to the 3.2-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:
lockdep-bug-exclude-taint_oot_module-from-disabling-lock-debugging.patch
and it can be found in the queue-3.2 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 9ec84acee1e221d99dc33237bff5e82839d10cc0 Mon Sep 17 00:00:00 2001
From: Ben Hutchings
Date: Wed, 7 Dec 2011 14:30:58 +
Subject: lockdep, bug: Exclude TAINT_OOT_MODULE from disabling lock debugging
From: Ben Hutchings
commit 9ec84acee1e221d99dc33237bff5e82839d10cc0 upstream.
We do want to allow lock debugging for GPL-compatible modules
that are not (yet) built in-tree. This was disabled as a
side-effect of commit 2449b8ba0745327c5fa49a8d9acffe03b2eded69
('module,bug: Add TAINT_OOT_MODULE flag for modules not built
in-tree'). Lock debug warnings now include taint flags, so
kernel developers should still be able to deflect warnings
caused by out-of-tree modules.
The TAINT_PROPRIETARY_MODULE flag for non-GPL-compatible modules
will still disable lock debugging.
Signed-off-by: Ben Hutchings
Cc: Nick Bowler
Cc: Dave Jones
Cc: Rusty Russell
Cc: Randy Dunlap
Cc: Debian kernel maintainers
Cc: Peter Zijlstra
Cc: Alan Cox
Link: http://lkml.kernel.org/r/1323268258.18450.11.camel@deadeye
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
kernel/panic.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -237,11 +237,12 @@ void add_taint(unsigned flag)
* Can't trust the integrity of the kernel anymore.
* We don't call directly debug_locks_off() because the issue
* is not necessarily serious enough to set oops_in_progress to 1
-* Also we want to keep up lockdep for staging development and
-* post-warning case.
+* Also we want to keep up lockdep for staging/out-of-tree
+* development and post-warning case.
*/
switch (flag) {
case TAINT_CRAP:
+ case TAINT_OOT_MODULE:
case TAINT_WARN:
case TAINT_FIRMWARE_WORKAROUND:
break;
Patches currently in stable-queue which might be from b...@decadent.org.uk are
queue-3.2/lockdep-bug-exclude-taint_firmware_workaround-from-disabling-lockdep.patch
queue-3.2/lockdep-bug-exclude-taint_oot_module-from-disabling-lock-debugging.patch
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/13287191523...@kroah.org
Patch "powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code" has been added to the 2.6.33-longterm tree
This is a note to let you know that I've just added the patch titled
powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code
to the 2.6.33-longterm tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.33.git;a=summary
The filename of the patch is:
powerpc-kexec-add-ifdef-config_ppc_std_mmu_64-to-ppc64-code.patch
and it can be found in the queue-2.6.33 subdirectory.
If you, or anyone else, feels it should not be added to the 2.6.33 longterm
tree,
please let know about it.
>From kamal...@linux.vnet.ibm.com Mon Apr 11 15:53:13 2011
From: Kamalesh Babulal
Date: Wed, 6 Apr 2011 18:31:45 +0530
Subject: powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code
To: Greg KH
Cc: Ben Hutchings , sta...@kernel.org, Debian kernel
maintainers , debian-rele...@lists.debian.org,
"Adam D. Barratt" , paul...@linux.vnet.ibm.com,
mi...@neuling.org, b...@kernel.crashing.org, an...@samba.org, dann frazier
, ga...@kernel.crashing.org
Message-ID: <20110406130145.gk28...@linux.vnet.ibm.com>
Content-Disposition: inline
From: Kamalesh Babulal
powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code
This patch introduces PPC64 specific #ifdef bits from the upstream
commit: b3df895aebe091b1657a42a8c859bd49fc96646b.
Reported-and-tested-by: dann frazier
Signed-off-by: Kumar Gala
Signed-off-by: Kamalesh Babulal
cc: Benjamin Herrenschmidt
cc: Anton Blanchard
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/crash.c |4
1 file changed, 4 insertions(+)
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -163,6 +163,7 @@ static void crash_kexec_prepare_cpus(int
}
/* wait for all the CPUs to hit real mode but timeout if they don't come in */
+#ifdef CONFIG_PPC_STD_MMU_64
static void crash_kexec_wait_realmode(int cpu)
{
unsigned int msecs;
@@ -187,6 +188,7 @@ static void crash_kexec_wait_realmode(in
}
mb();
}
+#endif
/*
* This function will be called by secondary cpus or by kexec cpu
@@ -445,7 +447,9 @@ void default_machine_crash_shutdown(stru
crash_kexec_prepare_cpus(crashing_cpu);
cpu_set(crashing_cpu, cpus_in_crash);
crash_kexec_stop_spus();
+#ifdef CONFIG_PPC_STD_MMU_64
crash_kexec_wait_realmode(crashing_cpu);
+#endif
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(1, 0);
}
Patches currently in longterm-queue-2.6.33 which might be from
kamal...@linux.vnet.ibm.com are
/home/gregkh/linux/longterm/longterm-queue-2.6.33/queue-2.6.33/powerpc-fix-default_machine_crash_shutdown-ifdef-botch.patch
/home/gregkh/linux/longterm/longterm-queue-2.6.33/queue-2.6.33/powerpc-kexec-add-ifdef-config_ppc_std_mmu_64-to-ppc64-code.patch
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/13025665893...@kroah.org
Patch "powerpc: Fix default_machine_crash_shutdown #ifdef botch" has been added to the 2.6.33-longterm tree
This is a note to let you know that I've just added the patch titled powerpc: Fix default_machine_crash_shutdown #ifdef botch to the 2.6.33-longterm tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.33.git;a=summary The filename of the patch is: powerpc-fix-default_machine_crash_shutdown-ifdef-botch.patch and it can be found in the queue-2.6.33 subdirectory. If you, or anyone else, feels it should not be added to the 2.6.33 longterm tree, please let know about it. >From kamal...@linux.vnet.ibm.com Mon Apr 11 15:53:40 2011 From: Kamalesh Babulal Date: Wed, 6 Apr 2011 18:34:48 +0530 Subject: powerpc: Fix default_machine_crash_shutdown #ifdef botch To: Greg KH Cc: Ben Hutchings , sta...@kernel.org, Debian kernel maintainers , debian-rele...@lists.debian.org, "Adam D. Barratt" , paul...@linux.vnet.ibm.com, mi...@neuling.org, b...@kernel.crashing.org, an...@samba.org, dann frazier , ga...@kernel.crashing.org Message-ID: <20110406130448.gl28...@linux.vnet.ibm.com> Content-Disposition: inline From: Kamalesh Babulal powerpc: Fix default_machine_crash_shutdown #ifdef botch Commit: c2be05481f6125254c45b78f334d4dd09c701c82 upstream crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64 and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP. Fix the conditional compilation around the invocation. Reported-by: Ben Hutchings Signed-off-by: Paul E. McKenney Acked-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh Babulal cc: Anton Blanchard Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/kernel/crash.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kernel/crash.c +++ b/arch/powerpc/kernel/crash.c @@ -447,7 +447,7 @@ void default_machine_crash_shutdown(stru crash_kexec_prepare_cpus(crashing_cpu); cpu_set(crashing_cpu, cpus_in_crash); crash_kexec_stop_spus(); -#ifdef CONFIG_PPC_STD_MMU_64 +#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP) crash_kexec_wait_realmode(crashing_cpu); #endif if (ppc_md.kexec_cpu_down) Patches currently in longterm-queue-2.6.33 which might be from kamal...@linux.vnet.ibm.com are /home/gregkh/linux/longterm/longterm-queue-2.6.33/queue-2.6.33/powerpc-fix-default_machine_crash_shutdown-ifdef-botch.patch /home/gregkh/linux/longterm/longterm-queue-2.6.33/queue-2.6.33/powerpc-kexec-add-ifdef-config_ppc_std_mmu_64-to-ppc64-code.patch -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/13025665883...@kroah.org
Patch "powerpc: Fix default_machine_crash_shutdown #ifdef botch" has been added to the 2.6.32-longterm tree
This is a note to let you know that I've just added the patch titled powerpc: Fix default_machine_crash_shutdown #ifdef botch to the 2.6.32-longterm tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary The filename of the patch is: powerpc-fix-default_machine_crash_shutdown-ifdef-botch.patch and it can be found in the queue-2.6.32 subdirectory. If you, or anyone else, feels it should not be added to the 2.6.32 longterm tree, please let know about it. >From kamal...@linux.vnet.ibm.com Mon Apr 11 15:53:40 2011 From: Kamalesh Babulal Date: Wed, 6 Apr 2011 18:34:48 +0530 Subject: powerpc: Fix default_machine_crash_shutdown #ifdef botch To: Greg KH Cc: Ben Hutchings , sta...@kernel.org, Debian kernel maintainers , debian-rele...@lists.debian.org, "Adam D. Barratt" , paul...@linux.vnet.ibm.com, mi...@neuling.org, b...@kernel.crashing.org, an...@samba.org, dann frazier , ga...@kernel.crashing.org Message-ID: <20110406130448.gl28...@linux.vnet.ibm.com> Content-Disposition: inline From: Kamalesh Babulal powerpc: Fix default_machine_crash_shutdown #ifdef botch Commit: c2be05481f6125254c45b78f334d4dd09c701c82 upstream crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64 and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP. Fix the conditional compilation around the invocation. Reported-by: Ben Hutchings Signed-off-by: Paul E. McKenney Acked-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh Babulal cc: Anton Blanchard Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/kernel/crash.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kernel/crash.c +++ b/arch/powerpc/kernel/crash.c @@ -447,7 +447,7 @@ void default_machine_crash_shutdown(stru crash_kexec_prepare_cpus(crashing_cpu); cpu_set(crashing_cpu, cpus_in_crash); crash_kexec_stop_spus(); -#ifdef CONFIG_PPC_STD_MMU_64 +#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP) crash_kexec_wait_realmode(crashing_cpu); #endif if (ppc_md.kexec_cpu_down) Patches currently in longterm-queue-2.6.32 which might be from kamal...@linux.vnet.ibm.com are /home/gregkh/linux/longterm/longterm-queue-2.6.32/queue-2.6.32/powerpc-fix-default_machine_crash_shutdown-ifdef-botch.patch /home/gregkh/linux/longterm/longterm-queue-2.6.32/queue-2.6.32/powerpc-kexec-add-ifdef-config_ppc_std_mmu_64-to-ppc64-code.patch -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/13025634211...@kroah.org
Patch "powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code" has been added to the 2.6.32-longterm tree
This is a note to let you know that I've just added the patch titled
powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code
to the 2.6.32-longterm tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary
The filename of the patch is:
powerpc-kexec-add-ifdef-config_ppc_std_mmu_64-to-ppc64-code.patch
and it can be found in the queue-2.6.32 subdirectory.
If you, or anyone else, feels it should not be added to the 2.6.32 longterm
tree,
please let know about it.
>From kamal...@linux.vnet.ibm.com Mon Apr 11 15:53:13 2011
From: Kamalesh Babulal
Date: Wed, 6 Apr 2011 18:31:45 +0530
Subject: powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code
To: Greg KH
Cc: Ben Hutchings , sta...@kernel.org, Debian kernel
maintainers , debian-rele...@lists.debian.org,
"Adam D. Barratt" , paul...@linux.vnet.ibm.com,
mi...@neuling.org, b...@kernel.crashing.org, an...@samba.org, dann frazier
, ga...@kernel.crashing.org
Message-ID: <20110406130145.gk28...@linux.vnet.ibm.com>
Content-Disposition: inline
From: Kamalesh Babulal
powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code
This patch introduces PPC64 specific #ifdef bits from the upstream
commit: b3df895aebe091b1657a42a8c859bd49fc96646b.
Reported-and-tested-by: dann frazier
Signed-off-by: Kumar Gala
Signed-off-by: Kamalesh Babulal
cc: Benjamin Herrenschmidt
cc: Anton Blanchard
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/crash.c |4
1 file changed, 4 insertions(+)
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -163,6 +163,7 @@ static void crash_kexec_prepare_cpus(int
}
/* wait for all the CPUs to hit real mode but timeout if they don't come in */
+#ifdef CONFIG_PPC_STD_MMU_64
static void crash_kexec_wait_realmode(int cpu)
{
unsigned int msecs;
@@ -187,6 +188,7 @@ static void crash_kexec_wait_realmode(in
}
mb();
}
+#endif
/*
* This function will be called by secondary cpus or by kexec cpu
@@ -445,7 +447,9 @@ void default_machine_crash_shutdown(stru
crash_kexec_prepare_cpus(crashing_cpu);
cpu_set(crashing_cpu, cpus_in_crash);
crash_kexec_stop_spus();
+#ifdef CONFIG_PPC_STD_MMU_64
crash_kexec_wait_realmode(crashing_cpu);
+#endif
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(1, 0);
}
Patches currently in longterm-queue-2.6.32 which might be from
kamal...@linux.vnet.ibm.com are
/home/gregkh/linux/longterm/longterm-queue-2.6.32/queue-2.6.32/powerpc-fix-default_machine_crash_shutdown-ifdef-botch.patch
/home/gregkh/linux/longterm/longterm-queue-2.6.32/queue-2.6.32/powerpc-kexec-add-ifdef-config_ppc_std_mmu_64-to-ppc64-code.patch
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/13025634212...@kroah.org
