Patch "Revert x86 sigcontext cleanups" has been added to the 4.1-stable tree
Subsystems (2)
This is a note to let you know that I've just added the patch titled
Revert x86 sigcontext cleanups
to the 4.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:
revert-x86-sigcontext-cleanups.patch
and it can be found in the queue-4.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
ed596cde9425509ec6ce88e19f03e9b13b6f518bMon Sep 17 00:00:00 2001
From: Linus Torvalds <[email protected]>
Date: Thu, 13 Aug 2015 08:25:20 -0700
Subject: Revert x86 sigcontext cleanups
From: Linus Torvalds <[email protected]>
commit ed596cde9425509ec6ce88e19f03e9b13b6f518b upstream.
This reverts commits 9a036b93a344 ("x86/signal/64: Remove 'fs' and 'gs' from sigcontext") and c6f2062935c8 ("x86/signal/64: Fix SS handling for signals delivered to 64-bit programs").
They were cleanups, but they break dosemu by changing the signal return behavior (and removing 'fs' and 'gs' from the sigcontext struct - while not actually changing any behavior - causes build problems).
--- arch/x86/include/asm/sigcontext.h | 6 +++--- arch/x86/include/uapi/asm/sigcontext.h | 21 +++------------------ arch/x86/kernel/signal.c | 26 +++++++++++--------------- 3 files changed, 17 insertions(+), 36 deletions(-)
arch/x86/include/asm/sigcontext.h +3 -3
@@ -57,9 +57,9 @@ struct sigcontext {unsigned long ip;unsigned long flags;unsigned short cs; -unsigned short __pad2;/* Was called gs, but was always zero. */ -unsigned short __pad1;/* Was called fs, but was always zero. */ -unsigned short ss; +unsigned short gs; +unsigned short fs; +unsigned short __pad0;unsigned long err;unsigned long trapno;unsigned long oldmask;
arch/x86/include/uapi/asm/sigcontext.h +3 -18
@@ -177,24 +177,9 @@ struct sigcontext {__u64 rip;__u64 eflags;/* RFLAGS */ __u16 cs; - -/* -* Prior to 2.5.64 ("[PATCH] x86-64 updates for 2.5.64-bk3"), -* Linux saved and restored fs and gs in these slots. This -* was counterproductive, as fsbase and gsbase were never -* saved, so arch_prctl was presumably unreliable. -* -* If these slots are ever needed for any other purpose, there -* is some risk that very old 64-bit binaries could get -* confused. I doubt that many such binaries still work, -* though, since the same patch in 2.5.64 also removed the -* 64-bit set_thread_area syscall, so it appears that there is -* no TLS API that works in both pre- and post-2.5.64 kernels. -*/ -__u16 __pad2;/* Was gs. */ -__u16 __pad1;/* Was fs. */ - -__u16 ss; +__u16 gs; +__u16 fs; +__u16 __pad0;__u64 err;__u64 trapno;__u64 oldmask;
arch/x86/kernel/signal.c +11 -15
@@ -93,8 +93,15 @@ int restore_sigcontext(struct pt_regs *rCOPY (r15);#endif /* CONFIG_X86_64 */ +#ifdef CONFIG_X86_32 COPY_SEG_CPL3 (cs);COPY_SEG_CPL3 (ss); +#else /* !CONFIG_X86_32 */ +/* Kernel saves and restores only the CS segment register on signals, +* which is the bare minimum needed to allow mixed 32/64-bit code. +* App's signal handler can save/restore other segments if needed. */ +COPY_SEG_CPL3 (cs); +#endif /* CONFIG_X86_32 */ get_user_ex (tmpflags, &sc->flags); regs->flags = (regs->flags & ~FIX_EFLAGS ) | (tmpflags &FIX_EFLAGS );
@@ -154,9 +161,8 @@ int setup_sigcontext(struct sigcontext _#else /* !CONFIG_X86_32 */ put_user_ex (regs->flags, &sc->flags);put_user_ex (regs->cs, &sc->cs); -put_user_ex (0 , &sc->__pad2); -put_user_ex (0 , &sc->__pad1); -put_user_ex (regs->ss, &sc->ss); +put_user_ex (0 , &sc->gs); +put_user_ex (0 , &sc->fs);#endif /* CONFIG_X86_32 */ put_user_ex (fpstate, &sc->fpstate);
@@ -450,19 +456,9 @@ static int __setup_rt_frame(int sig, str regs->sp = (unsigned long )frame; -/* -* Set up the CS and SS registers to run signal handlers in -* 64-bit mode, even if the handler happens to be interrupting -* 32-bit or 16-bit code. -* -* SS is subtle. In 64-bit mode, we don't need any particular -* SS descriptor, but we do need SS to be valid. It's possible -* that the old SS is entirely bogus -- this can happen if the -* signal we're trying to deliver is #GP or #SS caused by a bad -* SS value. -*/ +/* Set up the CS register to run signal handlers in 64-bit mode, +even if the handler happens to be interrupting 32-bit code. */ regs->cs = __USER_CS; - regs->ss = __USER_DS;return 0 ; }
Patches currently in stable-queue which might be from [email protected] are
queue-4.1/mm-hwpoison-fix-fail-isolate-hugetlbfs-page-w-refcount-held.patch queue-4.1/perf-fix-perf_event_ioc_period-migration-race.patch queue-4.1/ipc-sem.c-update-correct-memory-barriers.patch queue-4.1/ipc-sem-fix-use-after-free-on-ipc_rmid-after-a-task-using-same-semaphore-set-exits.patch queue-4.1/perf-fix-fasync-handling-on-inherited-events.patch queue-4.1/perf-fix-double-free-of-the-aux-buffer.patch queue-4.1/revert-x86-sigcontext-cleanups.patch queue-4.1/mm-hwpoison-fix-page-refcount-of-unknown-non-lru-page.patch