Re: [GIT PULL] x86/paravirt for v2.6.33

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 9 Dec 2009, H. Peter Anvin wrote:
> "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:
> >
> >But I'm not sure I understand the objection to task_pt_regs(); is it 
> >considered deprecated?   This patch received quite a lot of discussion 
> >with no mention of it.  Should we consider all its uses as suspect?

I personally would be much happier without ever seeing a single 
task_pt_regs() call outside of pure ptrace() users (and quite frankly, 
even there I'd be happier if it was basically done once, and then 'struct 
pt_regs' being passed around as an argument as much as possible).

In the case of 'ptrace' we control the stack of the tracee. 

In other cases, we do _not_.

For example, think about us ever implementing 'tasklets' or async system 
calls in general. It's _very_ possible that we'd have a special stolen 
stack for them, and run the low-level system call function from that 
stack. Then something like task_pt_regs() migth very well do the wrong 
thing.

Now, I'm not saying that 'sys_iopl()' would ever be a valid target for 
async system calls, but I _am_ saying that system calls that depend on 
task_pt_regs() are fundamnetally fragile and broken, and have subtle 
interactions.

In contrast, if you make it very explicit that the system call gets passed 
a pointer to its pt_regs, then it still has all the same issues, but now 
it's not subtle any more - now it's explicitly encoded in the call 
sequence on both the caller and callee sides, and somebody doing tasklets 
would hopefully see that "oh, iopl() has that same special thing that 
fork/clone/vfork/execve has, and touches the stack frame register set 
explicitly".

			Linus