| Message ID | 1442271047-4908-10-git-send-email-palmer@dabbelt.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 15 September 2015 10:06:07 Peter Zijlstra wrote: > > 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? If user space actually relies on the definition from this header file, then it will use the wrong one on x86 and get 'TYPE_DATA = 1', while the kernel uses 'TYPE_DATA = 0'. That seems unlikely to work, so I suspect it gets a different definition. If it uses this definition and it does work, we can probably use #if defined(__KERNEL__) && defined(CONFIG_HAVE_MIXED_BREAKPOINTS_REGS) but that requires a comment explaining exactly why that works. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Arnd Bergmann <arnd@arndb.de> wrote: > That seems unlikely to work, so I suspect it gets a different definition. > If it uses this definition and it does work, we can probably use > > #if defined(__KERNEL__) && defined(CONFIG_HAVE_MIXED_BREAKPOINTS_REGS) > > but that requires a comment explaining exactly why that works. Are you suggesting wrapping the entire construct in this within the UAPI header? David -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 15, 2015 at 11:15:29PM +0200, Arnd Bergmann wrote: > On Tuesday 15 September 2015 10:06:07 Peter Zijlstra wrote: > > > 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? > > If user space actually relies on the definition from this header file, > then it will use the wrong one on x86 and get 'TYPE_DATA = 1', while the > kernel uses 'TYPE_DATA = 0'. > > That seems unlikely to work, so I suspect it gets a different definition. > If it uses this definition and it does work, we can probably use > > #if defined(__KERNEL__) && defined(CONFIG_HAVE_MIXED_BREAKPOINTS_REGS) > > but that requires a comment explaining exactly why that works. I think this TYPE_DATA/TYPE_INST can be safely removed from uapi. This is only about internal kernel code. Userspace only relies on HW_BREAKPOINT_[R/W/X] to tell about the nature of the breakpoint. If userspace ever relies on it, which I have no idea why, it even needs to define CONFIG_HAVE_MIXED_BREAKPOINTS_REGS. No really there shouldn't be any user of that outside the kernel. Thanks. > > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -}; - #endif /* _UAPI_LINUX_HW_BREAKPOINT_H */ diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c index 92ce5f4ccc26..5ad117e0f55b 100644 --- a/kernel/events/hw_breakpoint.c +++ b/kernel/events/hw_breakpoint.c @@ -58,6 +58,16 @@ struct bp_cpuinfo { unsigned int flexible; /* XXX: placeholder, see fetch_this_slot() */ }; +enum bp_type_idx { + TYPE_INST = 0, +#if defined(CONFIG_HAVE_MIXED_BREAKPOINTS_REGS) + TYPE_DATA = 0, +#else + TYPE_DATA = 1, +#endif + TYPE_MAX +}; + static DEFINE_PER_CPU(struct bp_cpuinfo, bp_cpuinfo[TYPE_MAX]); static int nr_slots[TYPE_MAX];