Re: [PATCH] RFC x86_64 more accurate KSTK_ESP implementation

[Stefani Seibold]

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


--
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/