* [PATCH 0/2] xtensa queue 2013/10/15 for 3.12
@ 2013-10-14 22:22 Max Filippov
2013-10-14 22:22 ` [PATCH 1/2] xtensa: fix fast_syscall_spill_registers_fixup Max Filippov
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Max Filippov @ 2013-10-14 22:22 UTC (permalink / raw)
To: Chris Zankel
Cc: Marc Gauthier, Baruch Siach, linux-xtensa, linux-arch,
Max Filippov
Hi Chris,
could you please push these two fixes to the 3.12?
One fixes the regression introduced by the a3/excsave conversion in 3.12-rc1,
and the other fixes use of nonexistent alternative signal stack by threads.
You can pull these changes from my git tree,
the following changes since commit 61e6cfa80de5760bbe406f4e815b7739205754d2:
Linux 3.12-rc5 (2013-10-13 15:41:28 -0700)
are available in the git repository at:
git://github.com/jcmvbkbc/linux-xtensa.git xtensa-fixes-for-upstream
Baruch Siach (1):
xtensa: don't use alternate signal stack on threads
Max Filippov (1):
xtensa: fix fast_syscall_spill_registers_fixup
arch/xtensa/kernel/entry.S | 49 ++++++++++++++++++++++++++----------------
arch/xtensa/kernel/signal.c | 2 +-
2 files changed, 31 insertions(+), 20 deletions(-)
--
1.7.7.6
^ permalink raw reply [flat|nested] 5+ messages in thread* [PATCH 1/2] xtensa: fix fast_syscall_spill_registers_fixup 2013-10-14 22:22 [PATCH 0/2] xtensa queue 2013/10/15 for 3.12 Max Filippov @ 2013-10-14 22:22 ` Max Filippov 2013-10-14 22:22 ` [PATCH 2/2] xtensa: don't use alternate signal stack on threads Max Filippov 2013-10-15 17:58 ` [PATCH 0/2] xtensa queue 2013/10/15 for 3.12 Chris Zankel 2 siblings, 0 replies; 5+ messages in thread From: Max Filippov @ 2013-10-14 22:22 UTC (permalink / raw) To: Chris Zankel Cc: Marc Gauthier, Baruch Siach, linux-xtensa, linux-arch, Max Filippov fast_syscall_spill_registers_fixup was not correctly updated by the 'keep a3 and excsave1 on entry to exception handlers' patch: it doesn't preserve a3 that it gets on entry, breaking _spill_registers in case of page fault on stack during register spilling, leading to unhandled exception in kernel mode. Preserve a3 by saving it in the original _spill_registers stack frame's a3 during exception handling and restoring it afterwards. Also fix comments and function bounds annotations. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Tested-by: Baruch Siach <baruch@tkos.co.il> --- arch/xtensa/kernel/entry.S | 49 ++++++++++++++++++++++++++----------------- 1 files changed, 30 insertions(+), 19 deletions(-) diff --git a/arch/xtensa/kernel/entry.S b/arch/xtensa/kernel/entry.S index de1dfa1..21dbe6b 100644 --- a/arch/xtensa/kernel/entry.S +++ b/arch/xtensa/kernel/entry.S @@ -1122,7 +1122,7 @@ ENDPROC(fast_syscall_spill_registers) * a3: exctable, original value in excsave1 */ -fast_syscall_spill_registers_fixup: +ENTRY(fast_syscall_spill_registers_fixup) rsr a2, windowbase # get current windowbase (a2 is saved) xsr a0, depc # restore depc and a0 @@ -1134,22 +1134,26 @@ fast_syscall_spill_registers_fixup: */ xsr a3, excsave1 # get spill-mask - slli a2, a3, 1 # shift left by one + slli a3, a3, 1 # shift left by one - slli a3, a2, 32-WSBITS - src a2, a2, a3 # a1 = xxwww1yyxxxwww1yy...... + slli a2, a3, 32-WSBITS + src a2, a3, a2 # a2 = xxwww1yyxxxwww1yy...... wsr a2, windowstart # set corrected windowstart - rsr a3, excsave1 - l32i a2, a3, EXC_TABLE_DOUBLE_SAVE # restore a2 - l32i a3, a3, EXC_TABLE_PARAM # original WB (in user task) + srli a3, a3, 1 + rsr a2, excsave1 + l32i a2, a2, EXC_TABLE_DOUBLE_SAVE # restore a2 + xsr a2, excsave1 + s32i a3, a2, EXC_TABLE_DOUBLE_SAVE # save a3 + l32i a3, a2, EXC_TABLE_PARAM # original WB (in user task) + xsr a2, excsave1 /* Return to the original (user task) WINDOWBASE. * We leave the following frame behind: * a0, a1, a2 same - * a3: trashed (saved in excsave_1) + * a3: trashed (saved in EXC_TABLE_DOUBLE_SAVE) * depc: depc (we have to return to that address) - * excsave_1: a3 + * excsave_1: exctable */ wsr a3, windowbase @@ -1159,9 +1163,9 @@ fast_syscall_spill_registers_fixup: * a0: return address * a1: used, stack pointer * a2: kernel stack pointer - * a3: available, saved in EXCSAVE_1 + * a3: available * depc: exception address - * excsave: a3 + * excsave: exctable * Note: This frame might be the same as above. */ @@ -1181,9 +1185,12 @@ fast_syscall_spill_registers_fixup: rsr a0, exccause addx4 a0, a0, a3 # find entry in table l32i a0, a0, EXC_TABLE_FAST_USER # load handler + l32i a3, a3, EXC_TABLE_DOUBLE_SAVE jx a0 -fast_syscall_spill_registers_fixup_return: +ENDPROC(fast_syscall_spill_registers_fixup) + +ENTRY(fast_syscall_spill_registers_fixup_return) /* When we return here, all registers have been restored (a2: DEPC) */ @@ -1191,13 +1198,13 @@ fast_syscall_spill_registers_fixup_return: /* Restore fixup handler. */ - xsr a3, excsave1 - movi a2, fast_syscall_spill_registers_fixup - s32i a2, a3, EXC_TABLE_FIXUP - s32i a0, a3, EXC_TABLE_DOUBLE_SAVE - rsr a2, windowbase - s32i a2, a3, EXC_TABLE_PARAM - l32i a2, a3, EXC_TABLE_KSTK + rsr a2, excsave1 + s32i a3, a2, EXC_TABLE_DOUBLE_SAVE + movi a3, fast_syscall_spill_registers_fixup + s32i a3, a2, EXC_TABLE_FIXUP + rsr a3, windowbase + s32i a3, a2, EXC_TABLE_PARAM + l32i a2, a2, EXC_TABLE_KSTK /* Load WB at the time the exception occurred. */ @@ -1206,8 +1213,12 @@ fast_syscall_spill_registers_fixup_return: wsr a3, windowbase rsync + rsr a3, excsave1 + l32i a3, a3, EXC_TABLE_DOUBLE_SAVE + rfde +ENDPROC(fast_syscall_spill_registers_fixup_return) /* * spill all registers. -- 1.7.7.6 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH 2/2] xtensa: don't use alternate signal stack on threads 2013-10-14 22:22 [PATCH 0/2] xtensa queue 2013/10/15 for 3.12 Max Filippov 2013-10-14 22:22 ` [PATCH 1/2] xtensa: fix fast_syscall_spill_registers_fixup Max Filippov @ 2013-10-14 22:22 ` Max Filippov 2013-10-15 17:58 ` [PATCH 0/2] xtensa queue 2013/10/15 for 3.12 Chris Zankel 2 siblings, 0 replies; 5+ messages in thread From: Max Filippov @ 2013-10-14 22:22 UTC (permalink / raw) To: Chris Zankel Cc: Marc Gauthier, Baruch Siach, linux-xtensa, linux-arch, stable, Max Filippov From: Baruch Siach <baruch@tkos.co.il> According to create_thread(3): "The new thread does not inherit the creating thread's alternate signal stack". Since commit f9a3879a (Fix sigaltstack corruption among cloned threads), current->sas_ss_size is set to 0 for cloned processes sharing VM with their parent. Don't use the (nonexistent) alternate signal stack in this case. This has been broken since commit 29c4dfd9 ([XTENSA] Remove non-rt signal handling). Fixes the SA_ONSTACK part of the nptl/tst-cancel20 test from uClibc. Cc: <stable@vger.kernel.org> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> --- arch/xtensa/kernel/signal.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/xtensa/kernel/signal.c b/arch/xtensa/kernel/signal.c index 718eca1..98b67d5 100644 --- a/arch/xtensa/kernel/signal.c +++ b/arch/xtensa/kernel/signal.c @@ -341,7 +341,7 @@ static int setup_frame(int sig, struct k_sigaction *ka, siginfo_t *info, sp = regs->areg[1]; - if ((ka->sa.sa_flags & SA_ONSTACK) != 0 && ! on_sig_stack(sp)) { + if ((ka->sa.sa_flags & SA_ONSTACK) != 0 && sas_ss_flags(sp) == 0) { sp = current->sas_ss_sp + current->sas_ss_size; } -- 1.7.7.6 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 0/2] xtensa queue 2013/10/15 for 3.12 2013-10-14 22:22 [PATCH 0/2] xtensa queue 2013/10/15 for 3.12 Max Filippov 2013-10-14 22:22 ` [PATCH 1/2] xtensa: fix fast_syscall_spill_registers_fixup Max Filippov 2013-10-14 22:22 ` [PATCH 2/2] xtensa: don't use alternate signal stack on threads Max Filippov @ 2013-10-15 17:58 ` Chris Zankel 2013-10-15 18:29 ` Max Filippov 2 siblings, 1 reply; 5+ messages in thread From: Chris Zankel @ 2013-10-15 17:58 UTC (permalink / raw) To: Max Filippov; +Cc: Marc Gauthier, Baruch Siach, linux-xtensa, linux-arch Hi Max, Thanks for the patches. Is my assumption correct that this fixes memory faults while in double exception? And, instead of panic-ing, it works now but registers are likely wrong with ptrace? Also, should that go in for 3.12 (rc6?) or only in 3.13? Thanks, -Chris On 10/14/2013 03:22 PM, Max Filippov wrote: > Hi Chris, > > could you please push these two fixes to the 3.12? > One fixes the regression introduced by the a3/excsave conversion in 3.12-rc1, > and the other fixes use of nonexistent alternative signal stack by threads. > > You can pull these changes from my git tree, > the following changes since commit 61e6cfa80de5760bbe406f4e815b7739205754d2: > > Linux 3.12-rc5 (2013-10-13 15:41:28 -0700) > > are available in the git repository at: > git://github.com/jcmvbkbc/linux-xtensa.git xtensa-fixes-for-upstream > > Baruch Siach (1): > xtensa: don't use alternate signal stack on threads > > Max Filippov (1): > xtensa: fix fast_syscall_spill_registers_fixup > > arch/xtensa/kernel/entry.S | 49 ++++++++++++++++++++++++++---------------- > arch/xtensa/kernel/signal.c | 2 +- > 2 files changed, 31 insertions(+), 20 deletions(-) > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 0/2] xtensa queue 2013/10/15 for 3.12 2013-10-15 17:58 ` [PATCH 0/2] xtensa queue 2013/10/15 for 3.12 Chris Zankel @ 2013-10-15 18:29 ` Max Filippov 0 siblings, 0 replies; 5+ messages in thread From: Max Filippov @ 2013-10-15 18:29 UTC (permalink / raw) To: Chris Zankel Cc: Marc Gauthier, Baruch Siach, linux-xtensa@linux-xtensa.org, Linux-Arch On Tue, Oct 15, 2013 at 9:58 PM, Chris Zankel <chris@zankel.net> wrote: > Hi Max, > > Thanks for the patches. Is my assumption correct that this fixes memory > faults while in double exception? And, instead of panic-ing, it works > now but registers are likely wrong with ptrace? Well, one of them fixes the fixup handler for register spilling. It is not functional in xtensa-2.6.29-smp and I've blindly ported it with a3/excsave changes. If register spilling causes an exception current fixup handler messes up registers, which results in unrecoverable exception with very obscure trace. I don't think the fix has any effect on ptrace. This fix is not related to the issue with delivering signals generated in double exception, I haven't got chance to fix it it properly yet. Related ML thread: http://lists.linux-xtensa.org/pipermail/linux-xtensa/Week-of-Mon-20130909/001198.html http://lists.linux-xtensa.org/pipermail/linux-xtensa/Week-of-Mon-20130916/001209.html > Also, should that go in for 3.12 (rc6?) or only in 3.13? This is for 3.12. I have another (bigger :) pile for 3.13, will send it in a couple of days. > On 10/14/2013 03:22 PM, Max Filippov wrote: >> Hi Chris, >> >> could you please push these two fixes to the 3.12? >> One fixes the regression introduced by the a3/excsave conversion in 3.12-rc1, >> and the other fixes use of nonexistent alternative signal stack by threads. >> >> You can pull these changes from my git tree, >> the following changes since commit 61e6cfa80de5760bbe406f4e815b7739205754d2: >> >> Linux 3.12-rc5 (2013-10-13 15:41:28 -0700) >> >> are available in the git repository at: >> git://github.com/jcmvbkbc/linux-xtensa.git xtensa-fixes-for-upstream >> >> Baruch Siach (1): >> xtensa: don't use alternate signal stack on threads >> >> Max Filippov (1): >> xtensa: fix fast_syscall_spill_registers_fixup >> >> arch/xtensa/kernel/entry.S | 49 ++++++++++++++++++++++++++---------------- >> arch/xtensa/kernel/signal.c | 2 +- >> 2 files changed, 31 insertions(+), 20 deletions(-) >> -- Thanks. -- Max ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-10-15 18:29 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-10-14 22:22 [PATCH 0/2] xtensa queue 2013/10/15 for 3.12 Max Filippov 2013-10-14 22:22 ` [PATCH 1/2] xtensa: fix fast_syscall_spill_registers_fixup Max Filippov 2013-10-14 22:22 ` [PATCH 2/2] xtensa: don't use alternate signal stack on threads Max Filippov 2013-10-15 17:58 ` [PATCH 0/2] xtensa queue 2013/10/15 for 3.12 Chris Zankel 2013-10-15 18:29 ` Max Filippov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).