On Wed, Nov 8, 2017 at 7:12 AM, Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > I am not able to fully understand your concern. > > Can you point to a code file and line related to your observation? > > The patch is modeled after the existing modify_user_hw_breakpoint() function > > present in events/hw_breakpoint.c; don't you see this problem in that code? > > the reserve_bp_slot/release_bp_slot functions manage > counts for current breakpoints based on its type > > those counts are cumulated in here: > static DEFINE_PER_CPU(struct bp_cpuinfo, bp_cpuinfo[TYPE_MAX]); > > you allow to change the breakpoint type, so I'd expect > to see some code that release slot count for old type > and take new one (if it's available) > > jirka Why is this not a concern for modify_user_hw_breakpoint() function? -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
