Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c

From: Palmer Dabbelt <palmer@dabbelt.com>
To: peterz@infradead.org
Cc: arnd@arndb.de
Cc: dhowells@redhat.com
Cc: viro@zeniv.linux.org.uk
Cc: ast@plumgrid.com
Cc: aishchuk@linux.vnet.ibm.com
Cc: aarcange@redhat.com
Cc: akpm@linux-foundation.org
Cc: luto@kernel.org
Cc: acme@kernel.org
Cc: bhe@redhat.com
Cc: 3chas3@gmail.com
Cc: chris@zankel.net
Cc: dave@sr71.net
Cc: dyoung@redhat.com
Cc: drysdale@google.com
Cc: davem@davemloft.net
Cc: ebiederm@xmission.com
Cc: geoff@infradead.org
Cc: gregkh@linuxfoundation.org
Cc: hpa@zytor.com
Cc: mingo@kernel.org
Cc: iulia.manda21@gmail.com
Cc: plagnioj@jcrosoft.com
Cc: jikos@kernel.org
Cc: josh@joshtriplett.org
Cc: kexec@lists.infradead.org
Cc: linux-api@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-xtensa@linux-xtensa.org
Cc: mathieu.desnoyers@efficios.com
Cc: jcmvbkbc@gmail.com
Cc: paulmck@linux.vnet.ibm.com
Cc: tglx@linutronix.de
Cc: tomi.valkeinen@ti.com
Cc: vgoyal@redhat.com
Cc: x86@kernel.org
Cc: fweisbec@gmail.com
Subject: Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c
Date: Wed, 16 Sep 2015 20:56:00 -0700 (PDT)	[thread overview]
Message-ID: <55fa39d0.2c1b450a.6854.4115@mx.google.com> (raw)
In-Reply-To: <20150915193910.GH16853@twins.programming.kicks-ass.net>

On Tue, 15 Sep 2015 12:39:10 PDT (-0700), peterz@infradead.org wrote:
> On Tue, Sep 15, 2015 at 11:40:11AM -0700, Palmer Dabbelt wrote:
>> On Tue, 15 Sep 2015 01:06:07 PDT (-0700), peterz@infradead.org wrote:
>> > On Mon, Sep 14, 2015 at 03:50:43PM -0700, Palmer Dabbelt wrote:
>> >> This has a "#ifdef CONFIG_*" that used to be exposed to userspace.
>> >>
>> >> The names in here are so generic that I don't think it's a good idea
>> >> to expose them to userspace (or even the rest of the kernel).  Since
>> >> there's only one kernel user, it's been moved to that file.
>> >>
>> >> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
>> >> Reviewed-by: Andrew Waterman <waterman@eecs.berkeley.edu>
>> >> Reviewed-by: Albert Ou <aou@eecs.berkeley.edu>
>> >> ---
>> >>  include/uapi/linux/hw_breakpoint.h | 10 ----------
>> >>  kernel/events/hw_breakpoint.c      | 10 ++++++++++
>> >>  2 files changed, 10 insertions(+), 10 deletions(-)
>> >>
>> >> diff --git a/include/uapi/linux/hw_breakpoint.h b/include/uapi/linux/hw_breakpoint.h
>> >> index b04000a2296a..7a6a5a7f9511 100644
>> >> --- a/include/uapi/linux/hw_breakpoint.h
>> >> +++ b/include/uapi/linux/hw_breakpoint.h
>> >> @@ -17,14 +17,4 @@ enum {
>> >>  	HW_BREAKPOINT_INVALID   = HW_BREAKPOINT_RW | HW_BREAKPOINT_X,
>> >>  };
>> >>
>> >> -enum bp_type_idx {
>> >> -	TYPE_INST 	= 0,
>> >> -#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
>> >> -	TYPE_DATA	= 0,
>> >> -#else
>> >> -	TYPE_DATA	= 1,
>> >> -#endif
>> >> -	TYPE_MAX
>> >> -};
>> >
>> > This is rather unfortunate; you are correct that the naming is too
>> > generic (and I tend to agree), but I think these values are required by
>> > userspace to fill out:
>> >
>> >   perf_event_attr::bp_type
>> >
>> > So removing them will break things.
>> >
>> > Frederic?
>>
>> perf_event_open(2) says
>>
>>        bp_type (since Linux 2.6.33)
>>               This chooses the breakpoint type.  It is one of:
>>
>>               HW_BREAKPOINT_EMPTY
>>                      No breakpoint.
>>
>>               HW_BREAKPOINT_R
>>                      Count when we read the memory location.
>>
>>               HW_BREAKPOINT_W
>>                      Count when we write the memory location.
>>
>>               HW_BREAKPOINT_RW
>>                      Count when we read or write the memory location.
>>
>>               HW_BREAKPOINT_X
>>                      Count when we execute code at the memory location.
>>
>>               The values can be combined via a bitwise or, but the combination
>>               of HW_BREAKPOINT_R or HW_BREAKPOINT_W  with  HW_BREAKPOINT_X  is
>>               not allowed.
>>
>> so I think removing this enum from userspace is OK.  Did I miss
>> something?
>
> Nah, could've just been me not being awake. Unless Frederic says
> otherwise I'll chalk it up to not having drank enough morning juice.

Well, I'm going to leave this alone, then -- as Arnd pointed out in a
later email that got mis-threaded, this would be super tricky to fix
if userspace actually relied on it (which is why I was scared I was
wrong).

v4 (which is hopefully the final version of the patch set) will leave
this as it is.