[PATCH v2 0/6] Baby steps toward cleaning up KERNEL_STACK_OFFSET

[Andy Lutomirski]

Denys is right that KERNEL_STACK_OFFSET is a mess.  Let's start fixing
it.

This removes all C code that *reads* kernel_stack.  It also fixes the
KERNEL_STACK_OFFSET abomination in ia32_sysenter_target.

It does not fix the KERNEL_STACK_OFFSET abomination in GET_THREAD_INFO
and THREAD_INFO.  I think that should be its own patch.

It also doesn't change the two syscall targets.  To fix them, we should
make a decision.  Either we should make KERNEL_STACK_OFFSET have the
correct nonzero value to save an instruction or we should get rid of
kernel_stack entirely.

Changes from v1:
 - Fix missing export.
 - Fix lguest code.
 - Add more init_tss naming cleanups (Ingo's suggestion).
 - Changelog improvements (Ingo).
 - Improve the check in ist_begin_non_atomic (Denys).

Andy Lutomirski (6):
  x86: Add this_cpu_sp0() to read sp0 for the current cpu
  x86: Switch all C consumers of kernel_stack to this_cpu_sp0
  x86, asm: Change the 32-bit sysenter code to use sp0
  x86: Rename init_tss to cpu_tss
  x86: Remove INIT_TSS and fold the definitions into cpu_tss
  x86, asm: Rename INIT_TSS_IST to TSS_IST

 arch/x86/ia32/ia32entry.S          |  3 +--
 arch/x86/include/asm/processor.h   | 27 ++++++---------------------
 arch/x86/include/asm/thread_info.h |  3 +--
 arch/x86/kernel/asm-offsets_64.c   |  1 +
 arch/x86/kernel/cpu/common.c       |  6 +++---
 arch/x86/kernel/entry_64.S         |  6 +++---
 arch/x86/kernel/ioport.c           |  2 +-
 arch/x86/kernel/process.c          | 23 +++++++++++++++++++++--
 arch/x86/kernel/process_32.c       |  2 +-
 arch/x86/kernel/process_64.c       |  2 +-
 arch/x86/kernel/traps.c            |  4 ++--
 arch/x86/kernel/vm86_32.c          |  4 ++--
 arch/x86/lguest/boot.c             |  1 +
 arch/x86/power/cpu.c               |  2 +-
 arch/x86/xen/enlighten.c           |  1 +
 15 files changed, 46 insertions(+), 41 deletions(-)

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/