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)
commitaca9c293d098292579e345b2b39b394778d41526
tree8f8a588fb93856d39e124a7c47254ec153729eae
parentb235beea9e996a4d36fed6cfef4801a3e7d7a9a5
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