public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Oleg Nesterov <oleg@redhat.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: Fri, 9 Aug 2013 18:45:50 +0200	[thread overview]
Message-ID: <20130809164548.GD13339@somewhere> (raw)
In-Reply-To: <20130808181521.GA11138@redhat.com>

On Thu, Aug 08, 2013 at 08:15:21PM +0200, Oleg Nesterov wrote:
> 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.

(commented on the diff 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().

Hmm, but how moving that to arch_validate_hwbkpt_seetings() would solve
the issue?

> 
> 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;

Too bad we need to keep that compatibility around. Do you think this could be
a problem for AMD range breakpoints?

We can also fix the tools, then may be we'll be able to remove the kernel hack
compatibility in a few years.

Oh I need to check other archs as well.

thanks.

> +		if (bp->attr.bp_len == HW_BREAKPOINT_LEN_1)
> +			break;
>  	default:
>  		return -EINVAL;
>  	}
> 

  reply	other threads:[~2013-08-09 16:45 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
2013-08-09 16:45                   ` Frederic Weisbecker [this message]
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=20130809164548.GD13339@somewhere \
    --to=fweisbec@gmail.com \
    --cc=dvlasenk@redhat.com \
    --cc=felipe.contreras@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=notasas@gmail.com \
    --cc=oleg@redhat.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