linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@elte.hu>,
	Jan Kratochvil <jan.kratochvil@redhat.com>,
	Maneesh Soni <maneesh@linux.vnet.ibm.com>,
	Prasad <prasad@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] ptrace/x86: simplify ptrace_write_dr7()
Date: Sun, 14 Apr 2013 21:12:05 +0200	[thread overview]
Message-ID: <20130414191205.GA28791@redhat.com> (raw)

Hello.

On top of "[PATCH 0/5] kill ptrace_{get,put}_breakpoints()".
Cleanup and preparation for the potential fix, see below.

------------------------------------------------------------------------------
Now the question. Initially I was going to make more patches
and fix the regression introduced by 24f1e32c (although I am
not 100% sure which exactly patch should be blamed).

See https://bugzilla.redhat.com/show_bug.cgi?id=660204 for
details.

ptrace_write_dr7() does not create bp if it is zero, the comment
says:

	/*
	 * We should have at least an inactive breakpoint at
	 * this slot. It means the user is writing dr7 without
	 * having written the address register first.
	 */
                                                                                                    
and this looks logical. However, at least until 72f674d2
ptrace_set_debugreg(n => 7) worked even if addr wasn't set
by ptrace_set_debugreg(n => 0|1|2|3) before.

And note that ptrace_get_debugreg() does not fail if !ptrace_bps[n],
it just returns zero as if the address register was written. And
there is no way to know if address was actually set, not good and
not consistent.

Jan, Frederic, et all. What do you think we should do?

	1. Change ptrace_write_dr7() to do register_user_hw_breakpoint()
	   if necessary.

	   This is what I was going to do, but I am no longer sure
	   we want this. For what? Unlikely it is very useful to use
	   the "default" addr == 0 for debugging.

	2. Change ptrace_get_debugreg(0-4) to return -ESOMETHING if
	   ptrace_bps[n] == NULL.

	   This will match ptrace_set_debugreg(), but this can break
	   something else...

	3. Do nothing.

I am inclined to do "1", but please comment.

Oleg.


             reply	other threads:[~2013-04-14 19:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-14 19:12 Oleg Nesterov [this message]
2013-04-14 19:12 ` [PATCH 1/2] ptrace/x86: simplify the "disable" logic in ptrace_write_dr7() Oleg Nesterov
2013-04-16  0:03   ` Frederic Weisbecker
2013-04-14 19:12 ` [PATCH 2/2] ptrace/x86: dont delay perf_event_disable() till second pass " Oleg Nesterov
2013-04-16  0:44   ` Frederic Weisbecker
2013-04-16 13:30     ` Oleg Nesterov
2013-04-16 22:00       ` Frederic Weisbecker
2013-04-17 12:40         ` Oleg Nesterov
2013-04-14 19:30 ` [PATCH 0/2] ptrace/x86: simplify ptrace_write_dr7() Jan Kratochvil
2013-04-14 19:40   ` Oleg Nesterov
2013-04-15 23:36 ` Frederic Weisbecker
2013-04-16 13:25   ` Oleg Nesterov
2013-04-17  4:57     ` Jan Kratochvil

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=20130414191205.GA28791@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=jan.kratochvil@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maneesh@linux.vnet.ibm.com \
    --cc=mingo@elte.hu \
    --cc=prasad@linux.vnet.ibm.com \
    --cc=stern@rowland.harvard.edu \
    /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;
as well as URLs for NNTP newsgroup(s).