From: Andrew Morton <akpm@osdl.org>
To: davidm@hpl.hp.com
Cc: davidm@napali.hpl.hp.com, tony.luck@intel.com,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
roland@redhat.com
Subject: Re: [patch] add arch_ptrace_stop() hook and use it on ia64
Date: Tue, 10 May 2005 23:10:40 +0000 [thread overview]
Message-ID: <20050510161040.28b4a019.akpm@osdl.org> (raw)
In-Reply-To: <17025.6719.837031.411067@napali.hpl.hp.com>
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>
> The hook lets architectures do their own thing when a task stops for
> ptrace. In the case of ia64, we'd like to use this to update the
> user's virtual memory with the portion of the register-backing store
> that ended up on the kernel-stack.
>
> Note that the patch changes ptrace_stop() to release the
> sighand->siglock before setting the task to TASK_TRACED state. This
> is needed such that arch_ptrace_stop() can run without holding
> sighand->siglock (arch_ptrace_stop() may access user-memory and hence
> indirectly modify the task's run state and hence it is not possible to
> establish the TASK_TRACED state before running the hook).
Are we really sure about this? A quick peek at ptrace_check_attach() and
ptrace_untrace() (for example) indicates that we are using ->siglock to
synchronise access to the task state.
It's hard to see how swapping the assignment and the unlock in there could
break anything, but it does need to be gone through with a toothcomb
looking for synchronization issues as well as for missing memory barriers
(ptrace_check_attach doesn't use them, for example).
Nothing specific. Just .... worried.
next prev parent reply other threads:[~2005-05-10 23:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-10 20:31 [patch] add arch_ptrace_stop() hook and use it on ia64 David Mosberger
2005-05-10 23:10 ` Andrew Morton [this message]
2005-05-11 0:59 ` Roland McGrath
2005-05-11 8:55 ` David Mosberger
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=20050510161040.28b4a019.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=davidm@hpl.hp.com \
--cc=davidm@napali.hpl.hp.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=tony.luck@intel.com \
/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