On Wed, Nov 08, 2017 at 07:51:10AM -0800, Milind Chabbi wrote: > 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? I don't know ;-) jirka -- 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
