We can safely enable the breakpoint back for both the fail
and success paths by checking only the bp->attr.disabled,
which either holds the new 'requested' disabled state or
the original breakpoint state.
Suggested-by: Oleg Nesterov
Acked-by: Oleg Nesterov
Link:
We can safely enable the breakpoint back for both the fail
and success paths by checking only the bp->attr.disabled,
which either holds the new 'requested' disabled state or
the original breakpoint state.
Suggested-by: Oleg Nesterov
Acked-by: Oleg Nesterov
Link:
On 08/10, Jiri Olsa wrote:
>
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -2867,16 +2867,11 @@ static int perf_event_modify_breakpoint(struct
> perf_event *bp,
> _perf_event_disable(bp);
>
> err = modify_user_hw_breakpoint_check(bp, attr, true);
> - if (err) {
On 08/10, Jiri Olsa wrote:
>
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -2867,16 +2867,11 @@ static int perf_event_modify_breakpoint(struct
> perf_event *bp,
> _perf_event_disable(bp);
>
> err = modify_user_hw_breakpoint_check(bp, attr, true);
> - if (err) {
We can safely enable the breakpoint back for both the fail
and success paths by checking only the bp->attr.disabled,
which either holds the new 'requested' disabled state or
the original breakpoint state.
Suggested-by: Oleg Nesterov
Link:
We can safely enable the breakpoint back for both the fail
and success paths by checking only the bp->attr.disabled,
which either holds the new 'requested' disabled state or
the original breakpoint state.
Suggested-by: Oleg Nesterov
Link:
6 matches
Mail list logo