lkml.org 
[lkml]   [2009]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] x86/paravirt for v2.6.33


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


\
 
 \ /
  Last update: 2009-12-09 19:41    [W:0.038 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site