From: Alexander Nyberg <alexn@telia.com>
To: Stas Sergeev <stsp@aknet.ru>
Cc: Andrew Morton <akpm@osdl.org>,
torvalds@osdl.org, Mateusz Berezecki <mateuszb@gmail.com>,
linux-kernel@vger.kernel.org, zwane@arm.linux.org.uk
Subject: Re: 2.6.12-rc3 OOPS in vanilla source (once more)
Date: Wed, 04 May 2005 01:45:58 +0200 [thread overview]
Message-ID: <1115163958.945.76.camel@localhost.localdomain> (raw)
In-Reply-To: <4277B2EC.70605@aknet.ru>
> > So, my solution is to instead of just adjusting esp0 that creates an
> > inconsitent state I adjust where the user-space registers are saved with
> > -8 bytes.
> When I did that offending patch,
> I was thinking the following way:
> - Do we need to adjust that initial
> copy of child regs by the 8 bytes too?
> - Well, we need that 8 bytes only
> when the "struct pt_regs" is incomplete.
> Here we copy the *complete* "struct pt_regs",
> so shifting that here makes no sense.
>
> And so I adjusted only esp0 and
> nothing else. I think this may
> actually still be valid.
No I don't think it's valid. esp0 indicates the start of the stack and
right before it you copy the saved registers to a position that does not
correspond to this. And at this point, like you say we know the size of
what will be copied onto the stack so it makes even more sense to make
it correct from the beginning. Having inconsistent states is just asking
for more trouble.
> > This gives us the wanted extra bytes on the start of the stack
> > and esp0 is now correct.
> Yes, it is now correct by the mean
> that it points to the top of the
> "struct pt_regs" on the thread startup.
> However, it is not *always* points
> to the top of the "struct pt_regs".
> This -8 means exactly that esp0 can
> also point 8 bytes below the top of
> the "struct pt_regs" - that's what
> we've seen on a sysenter path, and
> that's what used crash either.
> So I think using esp0 to locate the
> top of the "struct pt_regs" is wrong.
> It doesn't always point to the top
> of that struct. Sometimes it does,
> but sometimes points 8 bytes lower.
> IMHO the ptrace.c have to be fixed
> instead so to not use this wrong
> assumption any more. What do you think?
>From my reading a task that is scheduled away cannot have a partial
saved pt_regs. If this is correct then ptrace won't suffer from this
problem as the traced child is scheduled away before the parent
investigates its status.
I need to look at the partial stack issue closer, don't think I fully
understand it yet.
next prev parent reply other threads:[~2005-05-03 23:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-02 14:04 2.6.12-rc3 OOPS in vanilla source (once more) Mateusz Berezecki
2005-05-03 3:05 ` Andrew Morton
2005-05-03 11:34 ` Alexander Nyberg
2005-05-03 17:20 ` Stas Sergeev
2005-05-03 23:45 ` Alexander Nyberg [this message]
2005-05-04 3:45 ` Stas Sergeev
2005-05-08 23:12 ` Mateusz Berezecki
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=1115163958.945.76.camel@localhost.localdomain \
--to=alexn@telia.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mateuszb@gmail.com \
--cc=stsp@aknet.ru \
--cc=torvalds@osdl.org \
--cc=zwane@arm.linux.org.uk \
/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