[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190117220924.GN6118@tassilo.jf.intel.com>
Date: Thu, 17 Jan 2019 14:09:24 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Stephane Eranian <eranian@...gle.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>, mingo@...e.hu,
"Liang, Kan" <kan.liang@...el.com>, Jiri Olsa <jolsa@...hat.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH] perf/core: fix perf_proc_update_handler() bug
On Thu, Jan 17, 2019 at 01:03:20PM -0800, Stephane Eranian wrote:
> On Thu, Jan 10, 2019 at 5:17 PM Stephane Eranian <eranian@...gle.com> wrote:
> >
> > The perf_proc_update_handler() handles /proc/sys/kernel/perf_event_max_sample_rate
> > syctl variable. When the PMU IRQ handler timing monitoring is disabled, i.e,
> > when /proc/sys/kernel/perf_cpu_time_max_percent is equal to 0 or 100,
> > then no modification to sysctl_perf_event_sample_rate is allowed to prevent
> > possible hang from wrong values.
> >
> > The problem is that the test to prevent modification is made after the
> > sysctl variable is modified in perf_proc_update_handler().
> >
> > You get an error:
> >
> > $ echo 10001 >/proc/sys/kernel/perf_event_max_sample_rate
> > echo: write error: invalid argument
> >
> > But the value is still modified causing all sorts of inconsistencies:
> >
> > $ cat /proc/sys/kernel/perf_event_max_sample_rate
> > 10001
> >
> > This patch fixes the problem by moving the parsing of the value after
> > the test.
> >
> > Signed-off-by: Stephane Eranian <eranian@...gle.com>
>
> Ping.
Reviewed-by: Andi Kleen <ak@...ux.intel.com>
-Andi
Powered by blists - more mailing lists