From: Petr Tesarik <ptesarik@suse.cz>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] ptrace RSE bug
Date: Wed, 05 Sep 2007 16:25:07 +0000 [thread overview]
Message-ID: <46DED863.4010307@suse.cz> (raw)
In-Reply-To: <1188357710.22637.7.camel@sli10-conroe.sh.intel.com>
Shaohua Li wrote:
> This is base kernel patch for ptrace RSE bug. It's basically a backport
> from the utrace RSE patch I sent out several weeks ago. please review.
>
> when a thread is stopped (ptraced), debugger might change thread's user
> stack (change memory directly), and we must avoid the RSE stored in
> kernel to override user stack (user space's RSE is newer than kernel's
> in the case). To workaround the issue, we copy kernel RSE to user RSE
> before the task is stopped, so user RSE has updated data. we then copy
> user RSE to kernel after the task is resummed from traced stop and
> kernel will use the newer RSE to return to user.
Hi Shaohua,
somehow I fail to see the need for a dedicated bit in the task flags.
The user RBS can only be more up-to-date than the kernel RBS if the
values there have been modified by a debugger. So, it should be enough
to copy the relevant part of the user RBS back into the kernel RBS when
the ptraced process is resumed, which happens AFAIK only:
1. when the debugger lets it continue via ptrace(), or
2. when the debugger ceases to exist.
Yes, we'd most likely have to add an arch_ptrace_resume() in addition to
arch_ptrace_stop(), but there are some advantages, too:
1. It would save one bit in the task flags.
2. The usual path for task switches is not modified
(OK, the few instructions needed to check for TIF_RESTORE_RSE are
negligible)
Or am I totally missing what you're trying to do?
Kind regards,
Petr Tesarik
next prev parent reply other threads:[~2007-09-05 16:25 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-29 3:21 [PATCH] ptrace RSE bug Shaohua Li
2007-08-29 7:10 ` Roland McGrath
2007-08-29 7:29 ` Matthew Chapman
2007-08-29 8:01 ` Roland McGrath
2007-09-05 16:25 ` Petr Tesarik [this message]
2007-09-06 3:16 ` Shaohua Li
2007-09-06 13:59 ` Petr Tesarik
2007-09-07 1:02 ` Shaohua Li
2007-09-07 8:26 ` Petr Tesarik
2007-09-07 15:11 ` David Mosberger-Tang
2007-09-11 8:39 ` Shaohua Li
2007-10-17 14:56 ` Petr Tesarik
2007-10-17 19:48 ` Petr Tesarik
2007-10-17 19:55 ` Petr Tesarik
2007-10-18 1:54 ` Shaohua Li
2007-10-18 10:59 ` Petr Tesarik
2007-10-18 16:02 ` Christoph Hellwig
2007-10-19 7:30 ` Shaohua Li
2007-10-19 19:42 ` Petr Tesarik
2007-10-24 3:34 ` Shaohua Li
2007-10-24 23:38 ` Luck, Tony
2007-10-25 0:38 ` Shaohua Li
2007-11-12 2:14 ` Roland McGrath
2007-11-12 15:41 ` Petr Tesarik
2007-11-12 16:11 ` Petr Tesarik
2007-11-13 0:30 ` Roland McGrath
2007-11-13 11:07 ` Petr Tesarik
2007-11-14 5:38 ` Shaohua Li
2007-11-14 6:47 ` Roland McGrath
2007-11-14 7:37 ` Petr Tesarik
2007-11-14 7:40 ` Roland McGrath
2007-11-14 7:53 ` Petr Tesarik
2007-11-14 7:55 ` Petr Tesarik
2007-11-14 11:09 ` Roland McGrath
2007-11-16 20:05 ` Petr Tesarik
2007-11-18 3:08 ` Roland McGrath
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=46DED863.4010307@suse.cz \
--to=ptesarik@suse.cz \
--cc=linux-ia64@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.