public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Grazvydas Ignotas <notasas@gmail.com>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>, Denys Vlasenko <dvlasenk@redhat.com>
Subject: Re: [PATCH 0/1] (Was: Linux 3.11-rc4)
Date: Thu, 8 Aug 2013 20:15:21 +0200	[thread overview]
Message-ID: <20130808181521.GA11138@redhat.com> (raw)
In-Reply-To: <20130808165427.GC32049@somewhere>

On 08/08, Frederic Weisbecker wrote:
>
> I'm all for fixing this. May be we can start by backporting a patch that
> ignores the value of gen_len for instruction breakpoints in x86?

Or perhaps we can start with the something like below.

But probably we should move "attr.bp_len == HW_BREAKPOINT_LEN_1" check
from arch_build_bp_info() to its caller, arch_validate_hwbkpt_settings().

Because:

> But this bp_len
> should rather be used for range breakpoints on archs that support it.

Yes, exactly, and we already have the patches for amd, so bp->len can
be actually != 1 but currently we can't support because it is checked
in arch_build_bp_info().

Oleg.

--- x/arch/x86/kernel/hw_breakpoint.c
+++ x/arch/x86/kernel/hw_breakpoint.c
@@ -208,19 +208,16 @@ int arch_bp_generic_fields(int x86_len, 
 {
 	/* Type */
 	switch (x86_type) {
-	case X86_BREAKPOINT_EXECUTE:
-		if (x86_len != X86_BREAKPOINT_LEN_X)
-			return -EINVAL;
-
-		*gen_type = HW_BREAKPOINT_X;
-		*gen_len = sizeof(long);
-		return 0;
 	case X86_BREAKPOINT_WRITE:
 		*gen_type = HW_BREAKPOINT_W;
 		break;
 	case X86_BREAKPOINT_RW:
 		*gen_type = HW_BREAKPOINT_W | HW_BREAKPOINT_R;
 		break;
+	case X86_BREAKPOINT_EXECUTE:
+		*gen_type = HW_BREAKPOINT_X;
+		if (x86_len == X86_BREAKPOINT_LEN_1)
+			break;
 	default:
 		return -EINVAL;
 	}
@@ -265,15 +262,11 @@ static int arch_build_bp_info(struct per
 		break;
 	case HW_BREAKPOINT_X:
 		info->type = X86_BREAKPOINT_EXECUTE;
-		/*
-		 * x86 inst breakpoints need to have a specific undefined len.
-		 * But we still need to check userspace is not trying to setup
-		 * an unsupported length, to get a range breakpoint for example.
-		 */
-		if (bp->attr.bp_len == sizeof(long)) {
-			info->len = X86_BREAKPOINT_LEN_X;
-			return 0;
-		}
+		/* until we change tools/perf */
+		if (bp->attr.bp_len == sizeof(long))
+			bp->attr.bp_len = HW_BREAKPOINT_LEN_1;
+		if (bp->attr.bp_len == HW_BREAKPOINT_LEN_1)
+			break;
 	default:
 		return -EINVAL;
 	}


  reply	other threads:[~2013-08-08 18:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-04 21:09 Linux 3.11-rc4 Linus Torvalds
2013-08-05  2:34 ` O_TMPFILE fs corruption (Re: Linux 3.11-rc4) Andy Lutomirski
2013-08-05  3:45   ` Linus Torvalds
2013-08-05  4:45     ` Andrew Lutomirski
2013-08-05  8:26     ` Christoph Hellwig
2013-08-05 16:04       ` Jörn Engel
2013-08-05 14:31     ` Al Viro
2013-08-05  4:20 ` Linux 3.11-rc4 Felipe Contreras
2013-08-05 13:29   ` Oleg Nesterov
2013-08-05 14:27     ` Felipe Contreras
2013-08-05 14:39       ` Oleg Nesterov
2013-08-05 17:02         ` Felipe Contreras
2013-08-05 17:11           ` Oleg Nesterov
2013-08-05 17:40             ` Felipe Contreras
2013-08-05 17:56               ` Oleg Nesterov
2013-08-05 17:39     ` Linus Torvalds
2013-08-05 17:43       ` Felipe Contreras
2013-08-05 18:08         ` Felipe Contreras
2013-08-05 17:47       ` Oleg Nesterov
2013-08-05 18:46   ` Oleg Nesterov
2013-08-05 18:54     ` Linus Torvalds
2013-08-05 18:57       ` Oleg Nesterov
2013-08-05 19:06         ` Linus Torvalds
2013-08-06 15:43   ` [PATCH 0/1] (Was: Linux 3.11-rc4) Oleg Nesterov
2013-08-06 15:43     ` [PATCH 1/1] Revert "ptrace: PTRACE_DETACH should do flush_ptrace_hw_breakpoint(child)" Oleg Nesterov
2013-08-07 12:05     ` [PATCH 0/1] (Was: Linux 3.11-rc4) Grazvydas Ignotas
2013-08-07 17:22       ` Oleg Nesterov
2013-08-07 19:26       ` Linus Torvalds
2013-08-07 19:27         ` Oleg Nesterov
2013-08-07 19:47           ` Linus Torvalds
2013-08-08 15:41             ` Oleg Nesterov
2013-08-08 16:25               ` Linus Torvalds
2013-08-08 16:54               ` Frederic Weisbecker
2013-08-08 18:15                 ` Oleg Nesterov [this message]
2013-08-09 16:45                   ` Frederic Weisbecker
2013-08-09 17:12                     ` 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=20130808181521.GA11138@redhat.com \
    --to=oleg@redhat.com \
    --cc=dvlasenk@redhat.com \
    --cc=felipe.contreras@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=notasas@gmail.com \
    --cc=torvalds@linux-foundation.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