From: Ingo Molnar <mingo@elte.hu>
To: Frederic Weisbecker <fweisbec@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Will Deacon <will.deacon@arm.com>,
Prasad <prasad@linux.vnet.ibm.com>,
Paul Mundt <lethal@linux-sh.org>, "v2.6.33.." <stable@kernel.org>,
Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH 1/5] ptrace: Prepare to fix racy accesses on task breakpoints
Date: Wed, 4 May 2011 08:31:06 +0200 [thread overview]
Message-ID: <20110504063106.GA20140@elte.hu> (raw)
In-Reply-To: <1304429124-2376-2-git-send-email-fweisbec@gmail.com>
(Linus and Andrew Cc:-ed as well)
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> When a task is traced and is in a stopped state, the tracer
> may execute a ptrace request to examine the tracee state and
> get its task struct. Right after, the tracee can be killed
> and thus its breakpoints released.
> This can happen concurrently when the tracer is in the middle
> of reading or modifying these breakpoints, leading to dereferencing
> a freed pointer.
>
> Hence, to prepare the fix, create a generic breakpoint reference
> holding API. When a reference on the breakpoints of a task is
> held, the breakpoints won't be released until the last reference
> is dropped. After that, no more ptrace request on the task's
> breakpoints can be serviced for the tracer.
>
> Reported-by: Oleg Nesterov <oleg@redhat.com>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Ok, this series looks a bit scary - and this ptrace.h change does not have
Oleg's Acked-by. (the arch bits all have maintaner Acked-by's)
The changes look a bit ugly as well: beyond the ugly ifdeffery, we have
ptrace.h::ptrace_init_task(), which is only used in
tracehook.h::tracehook_finish_clone() which is only used in
kernel/fork.c::copy_process().
That's two levels of obfuscation to do something rather simple - i think we
should get rid of the tracehook.h redirections, it did not work out in the end
as a method of capturing events - ftrace TRACE_EVENT() seems better structured
and more maintainable.
But i guess we could live with this fix for v2.6.39, if neither Oleg nor Linus
and Andrew are hating this further complication of the ptrace mess enough to
NAK it. Thoughts?
Plus, i'd really love it if you did some stress-testing of this change of a
mixed ptrace breakpoints and perf breakpoints workload, on some sufficiently
SMP box. gdb's hbreak is a very low freq way of testing thus such regressions
take ages to be reported.
Thanks,
Ingo
next prev parent reply other threads:[~2011-05-04 6:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-03 13:25 [GIT PULL] hw_breakpoint fixes Frederic Weisbecker
2011-05-03 13:25 ` [PATCH 1/5] ptrace: Prepare to fix racy accesses on task breakpoints Frederic Weisbecker
2011-05-04 6:31 ` Ingo Molnar [this message]
2011-05-04 18:22 ` Frederic Weisbecker
2011-05-03 13:25 ` [PATCH 2/5] x86, hw_breakpoints: Fix racy access to ptrace breakpoints Frederic Weisbecker
2011-05-03 13:25 ` [PATCH 3/5] powerpc, " Frederic Weisbecker
2011-05-03 13:25 ` [PATCH 4/5] arm, " Frederic Weisbecker
2011-05-03 13:25 ` [PATCH 5/5] sh, " Frederic Weisbecker
-- strict thread matches above, loose matches on Subject: below --
2011-04-08 17:34 [PATCH 0/5] hw_breakpoints: Fix racy ptrace breakpoint acccesses Frederic Weisbecker
2011-04-08 17:34 ` [PATCH 1/5] ptrace: Prepare to fix racy accesses on task breakpoints Frederic Weisbecker
2011-04-11 10:47 ` Will Deacon
2011-04-12 17:54 ` Frederic Weisbecker
2011-04-13 14:34 ` Will Deacon
2011-04-13 15:10 ` Frederic Weisbecker
2011-04-25 17:37 ` Frederic Weisbecker
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=20110504063106.GA20140@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=prasad@linux.vnet.ibm.com \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.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