From: Roland McGrath <roland@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: David Howells <dhowells@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Frysinger <vapier@gentoo.org>,
linux-sh@vger.kernel.org, Paul Mundt <lethal@linux-sh.org>,
uclinux-dist-devel@blackfin.uclinux.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 1/1] ptrace: PTRACE_GETFDPIC: fix the unsafe usage of child->mm
Date: Mon, 24 May 2010 16:42:50 -0700 (PDT) [thread overview]
Message-ID: <20100524234250.F158849A56@magilla.sf.frob.com> (raw)
In-Reply-To: Oleg Nesterov's message of Monday, 24 May 2010 17:14:45 +0200 <20100524151445.GA6393@redhat.com>
> You mean, pass it to arch_ptrace() ?
>
> grep, grep, grep. I guess I understand you. We have more unsafe code
> like this in arch/*/kernel/ptrace.c. Of course, it can be fixed without
> doing get_task_mm() in sys_ptrace(), but perhaps it would be more clean
> to do what you suggest.
>
> Roland, what do you think?
The mm pointer is only used by these uncommon ptrace operations that exist
only in certain unusual arch's (and they're all ill-advised old arch ptrace
ABI additions, at that). It doesn't seem wise to pay the overhead for
get_task_mm()/mmput() on every ptrace call, 99.44% of which don't use it
(and 100% on 90% of machines).
If you were to make any change to the signature of arch_ptrace() it should
be one big change to use a struct ptrace_params or suchlike, also passed
down to ptrace_request(). Then any future needs to pass around more
information won't require changing the code in all the arch code that
doesn't look at the new parameter.
Thanks,
Roland
next prev parent reply other threads:[~2010-05-24 23:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-16 0:30 [PATCH] ptrace: unify FDPIC implementations Mike Frysinger
2010-02-16 1:10 ` Paul Mundt
2010-02-16 8:12 ` Mike Frysinger
2010-05-21 8:42 ` [PATCH v2] " Mike Frysinger
2010-05-21 16:26 ` Oleg Nesterov
2010-05-21 18:35 ` Roland McGrath
2010-05-22 16:53 ` [PATCH -mm 0/1] (Was: ptrace: unify FDPIC implementations) Oleg Nesterov
2010-05-22 16:54 ` [PATCH -mm 1/1] ptrace: PTRACE_GETFDPIC: fix the unsafe usage of child->mm Oleg Nesterov
2010-05-24 4:33 ` [Uclinux-dist-devel] " Mike Frysinger
2010-05-24 8:38 ` Roland McGrath
2010-05-24 14:36 ` David Howells
2010-05-24 15:14 ` Oleg Nesterov
2010-05-24 23:42 ` Roland McGrath [this message]
2010-05-25 1:29 ` [Uclinux-dist-devel] " Mike Frysinger
2010-05-25 19:11 ` Roland McGrath
2010-05-25 9:14 ` David Howells
2010-05-25 10:23 ` Oleg Nesterov
2010-05-25 17:28 ` Mike Frysinger
2010-05-26 12:40 ` Oleg Nesterov
2010-05-27 19:55 ` [PATCH 0/2] blackfin: ptrace mm/sram_list fixes Oleg Nesterov
2010-05-27 19:56 ` [PATCH 1/2] blackfin: ptrace: fix the unsafe usage of mm/find_vma in is_user_addr_valid() Oleg Nesterov
2010-05-27 19:56 ` [PATCH 2/2] blackfin: use ->mmap_sem to protect mm_context_t->sram_list Oleg Nesterov
2010-05-27 20:21 ` [PATCH 0/2] blackfin: ptrace mm/sram_list fixes Mike Frysinger
2010-05-28 19:43 ` Oleg Nesterov
2010-05-25 12:24 ` [PATCH -mm 1/1] ptrace: PTRACE_GETFDPIC: fix the unsafe usage of child->mm David Howells
2010-05-25 12:30 ` Oleg Nesterov
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=20100524234250.F158849A56@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=uclinux-dist-devel@blackfin.uclinux.org \
--cc=vapier@gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®