linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
To: x86@kernel.org
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	linux-kernel@vger.kernel.org, Jamie Lokier <jamie@shareable.org>,
	Mike Frysinger <vapier@gentoo.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Subject: [PATCH] x86_64: Record stack pointer before task execution begins
Date: Sun, 26 Feb 2012 21:47:55 +0530	[thread overview]
Message-ID: <1330273075-2949-1-git-send-email-siddhesh.poyarekar@gmail.com> (raw)
In-Reply-To: <CAAHN_R3zjh-xQ9yW57JhQ=AiJG+DV6D_ppveh3BvUYy8NWU3Lg@mail.gmail.com>

task->thread.usersp is unusable immediately after a binary is exec()'d
until it undergoes a context switch cycle. The start_thread() function
called during execve() saves the stack pointer into pt_regs and into
old_rsp, but fails to record it into task->thread.usersp.

Because of this, KSTK_ESP(task) returns an incorrect value for a
64-bit program until the task is switched out and back in since
switch_to swaps %rsp values in and out into task->thread.usersp.

Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
---
 arch/x86/kernel/process_64.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 9b9fe4a..702a3b9 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -341,6 +341,7 @@ start_thread_common(struct pt_regs *regs, unsigned long new_ip,
 	loadsegment(es, _ds);
 	loadsegment(ds, _ds);
 	load_gs_index(0);
+	current->thread.usersp	= new_sp;
 	regs->ip		= new_ip;
 	regs->sp		= new_sp;
 	percpu_write(old_rsp, new_sp);
-- 
1.7.7.4


  reply	other threads:[~2012-02-26 16:17 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-14 12:35 [PATCH] Mark thread stack correctly in proc/<pid>/maps Siddhesh Poyarekar
2012-01-16 11:28 ` Jamie Lokier
2012-01-16 13:08   ` Siddhesh Poyarekar
2012-01-16 16:31     ` Jamie Lokier
2012-01-16 17:01       ` Siddhesh Poyarekar
2012-01-17  4:54       ` Siddhesh Poyarekar
2012-02-02  6:24         ` [RESEND][PATCH] " Siddhesh Poyarekar
2012-02-02 21:40           ` KOSAKI Motohiro
2012-02-03  7:09             ` Siddhesh Poyarekar
2012-02-03  8:01               ` KOSAKI Motohiro
2012-02-03  9:49                 ` Siddhesh Poyarekar
2012-02-03 10:29                 ` Mike Frysinger
2012-02-03 18:34                 ` Siddhesh Poyarekar
2012-02-08  4:00                   ` Siddhesh Poyarekar
2012-02-08 17:57                     ` KOSAKI Motohiro
2012-02-11 10:19                       ` Siddhesh Poyarekar
2012-02-11 15:03                       ` [PATCH] " Siddhesh Poyarekar
2012-02-21  4:24                         ` [RESEND][PATCH] " Siddhesh Poyarekar
2012-02-22 23:00                           ` Andrew Morton
2012-02-23  4:03                             ` [PATCH] " Siddhesh Poyarekar
2012-02-23 20:22                               ` Andrew Morton
2012-02-24 13:05                                 ` Siddhesh Poyarekar
2012-02-26 16:17                                   ` Siddhesh Poyarekar [this message]
2012-02-27  6:17                                     ` [tip:x86/process] x86_64: Record stack pointer before task execution begins tip-bot for Siddhesh Poyarekar
2012-02-23 23:47                               ` [PATCH] Mark thread stack correctly in proc/<pid>/maps Mike Frysinger
2012-02-24  5:47                                 ` Siddhesh Poyarekar
2012-02-24 16:12                                   ` Mike Frysinger
2012-02-24 18:23                                     ` Siddhesh Poyarekar
2012-03-01  5:20                                     ` [PATCH 1/2] Take rcu read lock when iterating through thread group Siddhesh Poyarekar
2012-03-01  5:20                                       ` [PATCH 2/2] procfs: Mark stack vma with pid of the owning task Siddhesh Poyarekar
2012-03-01 23:17                                         ` Andrew Morton
2012-03-01 16:51                                       ` [PATCH 1/2] Take rcu read lock when iterating through thread group Oleg Nesterov
2012-03-01 23:21                                       ` Andrew Morton
2012-03-04 20:04                                         ` Siddhesh Poyarekar
2012-02-23 23:17                         ` [PATCH] Mark thread stack correctly in proc/<pid>/maps KOSAKI Motohiro
2012-02-24  0:49                           ` KOSAKI Motohiro
2012-02-24  5:29                           ` Siddhesh Poyarekar
2012-02-24 16:14                             ` KOSAKI Motohiro
2012-02-24 18:58                               ` Siddhesh Poyarekar
  -- strict thread matches above, loose matches on Subject: below --
2012-02-28 17:04 + procfs-mark-thread-stack-correctly-in-proc-pid-maps.patch added to -mm tree Oleg Nesterov
2012-02-28 17:18 ` Siddhesh Poyarekar
2012-02-28 17:40   ` Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1330273075-2949-1-git-send-email-siddhesh.poyarekar@gmail.com \
    --to=siddhesh.poyarekar@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=jamie@shareable.org \
    --cc=kosaki.motohiro@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=vapier@gentoo.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).