public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefani Seibold <stefani@seibold.net>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Americo Wang <xiyou.wangcong@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] RFC x86_64 more accurate KSTK_ESP implementation
Date: Thu, 05 Nov 2009 13:11:03 +0100	[thread overview]
Message-ID: <1257423063.961.10.camel@wall-e> (raw)
In-Reply-To: <20091105110857.GR31511@one.firstfloor.org>

Am Donnerstag, den 05.11.2009, 12:08 +0100 schrieb Andi Kleen:
> > +void update_usersp(struct pt_regs *regs)
> > +{
> > +	unsigned long stk = (unsigned long)task_stack_page(current);
> > +	unsigned long stkp = (regs)->sp; 
> > +
> > +	if (((stkp < stk) || (stkp >= stk + THREAD_SIZE))
> > +	    && regs->ip < PAGE_OFFSET)
> > +		percpu_write(old_rsp, stkp);
> 
> This does not handle interrupt and exception stacks correctly.
> 
> Also regs->ip is never a safe check for running in user space,
> because a program can set the IP to a arbitrary value for a one
> instruction window.
> 

I think this doesn't matter, because i want only detect if it is save to
wrire the old_rsp value. There are only three places in the kernel where
this value will be writen, all of them are in the kernel. So checking if
the ip is in the kernel and the stack pointer points outside the kernel
stack of the current task will be enough. Or i am wrong?

> The larger problem is also if the kernel moves to no-tick-for-non-idle
> (which I guess will happen sooner or later) your method won't
> work anyways, or again be arbitarily inaccurate. Even today 10ms
> worst time inaccuracy for HZ=100 is rather bad, there can be a lot of stack
> allocations in that time. And adding new dependencies on a regular
> timer when everything else is moving away from that doesn't seem right.

The value is correct in case of on uni processor system. In an multi
core system it is a good approximation. A quick look into other
architectures shows that this is not a x86_64 issue. All architecture
give you only a snapshot.

But this is good enough for ps or /proc usage. If someone want an exact
value, then it is necessary to stop the task.

> 
> Also I suspect this method won't work on preempt-rt without 
> additional tweaks.
> 

That is a other issue. Let us first fix and agree about the basics.

Stefani



  reply	other threads:[~2009-11-05 12:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-03  7:31 [PATCH] update fix X86_64 procfs provide stack information for threads Stefani Seibold
2009-11-03  8:28 ` Ingo Molnar
2009-11-03  9:06   ` Stefani Seibold
2009-11-03 18:16     ` Ingo Molnar
2009-11-05  8:19     ` [PATCH] RFC x86_64 more accurate KSTK_ESP implementation Stefani Seibold
2009-11-05 11:08       ` Andi Kleen
2009-11-05 12:11         ` Stefani Seibold [this message]
2009-11-08 11:35       ` Ingo Molnar
2009-11-08 12:51         ` Stefani Seibold
2009-11-08 12:55           ` Ingo Molnar
2009-11-08 14:00             ` Stefani Seibold
2009-11-08 16:34               ` H. Peter Anvin
2009-11-08 19:37         ` Andi Kleen
2009-11-05 13:02     ` [PATCH] fix /proc/<pid>/stat stack pointer for kernel threads Stefani Seibold
2009-11-13  8:01     ` [tip:x86/urgent] fs: " Stefani Seibold
2009-11-04 11:17 ` [PATCH] update fix X86_64 procfs provide stack information for threads Andi Kleen
2009-11-04 11:50   ` Stefani Seibold
2009-11-04 12:00     ` Andi Kleen
2009-11-04 12:22       ` Stefani Seibold
2009-11-04 15:42       ` Stefani Seibold
2009-11-04 22:21       ` Stefani Seibold

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=1257423063.961.10.camel@wall-e \
    --to=stefani@seibold.net \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=xiyou.wangcong@gmail.com \
    /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