x86: fix up a few misc stack pointer vs thread_info confusions
authorLinus Torvalds <torvalds@linux-foundation.org>
Fri, 24 Jun 2016 23:55:53 +0000 (16:55 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Fri, 24 Jun 2016 23:55:53 +0000 (16:55 -0700)
commit450b797db5f165f750e131c1c216a14d8e7fe4ce
tree8f8a588fb93856d39e124a7c47254ec153729eae
parentdd0241b77a84f5d45d96f8d97dbb80295b9242cb
x86: fix up a few misc stack pointer vs thread_info confusions

As the actual pointer value is the same for the thread stack allocation
and the thread_info, code that confused the two worked fine, but will
break when the thread info is moved away from the stack allocation.  It
also looks very confusing.

For example, the kprobe code wanted to know the current top of stack.
To do that, it used this:

(unsigned long)current_thread_info() + THREAD_SIZE

which did indeed give the correct value.  But it's not only a fairly
nonsensical expression, it's also rather complex, especially since we
actually have this:

static inline unsigned long current_top_of_stack(void)

which not only gives us the value we are interested in, but happens to
be how "current_thread_info()" is currently defined as:

(struct thread_info *)(current_top_of_stack() - THREAD_SIZE);

so using current_thread_info() to figure out the top of the stack really
is a very round-about thing to do.

The other cases are just simpler confusion about task_thread_info() vs
task_stack_page(), which currently return the same pointer - but if you
want the stack page, you really should be using the latter one.

And there was one entirely unused assignment of the current stack to a
thread_info pointer.

All cleaned up to make more sense today, and make it easier to move the
thread_info away from the stack in the future.

No semantic changes.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
arch/x86/include/asm/kprobes.h
arch/x86/kernel/dumpstack.c
arch/x86/kernel/irq_32.c