* Re: [tip:perf/urgent] perf/core: Fix perf_event_disable_inatomic() race
[not found] <tip-86071b11317550d994b55ce5e31aa06bcad783b5@git.kernel.org>
@ 2019-04-11 13:04 ` Peter Zijlstra
2019-04-12 6:55 ` Ingo Molnar
0 siblings, 1 reply; 2+ messages in thread
From: Peter Zijlstra @ 2019-04-11 13:04 UTC (permalink / raw)
To: mark.rutland, mingo, acme, tglx, brueckner, torvalds,
alexander.shishkin, heiko.carstens, tmricht, schwidefsky,
linux-kernel, keescook, jolsa, hpa
Cc: linux-tip-commits
On Wed, Apr 10, 2019 at 05:13:54AM -0700, tip-bot for Peter Zijlstra wrote:
> Commit-ID: 86071b11317550d994b55ce5e31aa06bcad783b5
> Gitweb: https://git.kernel.org/tip/86071b11317550d994b55ce5e31aa06bcad783b5
> Author: Peter Zijlstra <peterz@infradead.org>
> AuthorDate: Thu, 4 Apr 2019 15:03:00 +0200
> Committer: Ingo Molnar <mingo@kernel.org>
> CommitDate: Wed, 10 Apr 2019 13:47:09 +0200
>
> perf/core: Fix perf_event_disable_inatomic() race
>
> Thomas-Mich Richter reported he triggered a WARN()ing from event_function_local()
> on his s390. The problem boils down to:
>
> CPU-A CPU-B
>
> perf_event_overflow()
> perf_event_disable_inatomic()
> @pending_disable = 1
> irq_work_queue();
>
> sched-out
> event_sched_out()
> @pending_disable = 0
>
> sched-in
> perf_event_overflow()
> perf_event_disable_inatomic()
> @pending_disable = 1;
> irq_work_queue(); // FAILS
>
> irq_work_run()
> perf_pending_event()
> if (@pending_disable)
> perf_event_disable_local(); // WHOOPS
>
> The problem exists in generic, but s390 is particularly sensitive
> because it doesn't implement arch_irq_work_raise(), nor does it call
> irq_work_run() from it's PMU interrupt handler (nor would that be
> sufficient in this case, because s390 also generates
> perf_event_overflow() from pmu::stop). Add to that the fact that s390
> is a virtual architecture and (virtual) CPU-A can stall long enough
> for the above race to happen, even if it would self-IPI.
>
> Adding a irq_work_sync() to event_sched_in() would work for all hardare
> PMUs that properly use irq_work_run() but fails for software PMUs.
>
> Instead encode the CPU number in @pending_disable, such that we can
> tell which CPU requested the disable. This then allows us to detect
> the above scenario and even redirect the IPI to make up for the failed
> queue.
Ingo, could you please fold in the below delta? It turns out I
overlooked two insteances :-(
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -392,7 +392,7 @@ void *perf_aux_output_begin(struct perf_
* store that will be enabled on successful return
*/
if (!handle->size) { /* A, matches D */
- event->pending_disable = 1;
+ event->pending_disable = smp_processor_id();
perf_output_wakeup(handle);
local_set(&rb->aux_nest, 0);
goto err_put;
@@ -480,7 +480,7 @@ void perf_aux_output_end(struct perf_out
if (wakeup) {
if (handle->aux_flags & PERF_AUX_FLAG_TRUNCATED)
- handle->event->pending_disable = 1;
+ handle->event->pending_disable = smp_processor_id();
perf_output_wakeup(handle);
}
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [tip:perf/urgent] perf/core: Fix perf_event_disable_inatomic() race
2019-04-11 13:04 ` [tip:perf/urgent] perf/core: Fix perf_event_disable_inatomic() race Peter Zijlstra
@ 2019-04-12 6:55 ` Ingo Molnar
0 siblings, 0 replies; 2+ messages in thread
From: Ingo Molnar @ 2019-04-12 6:55 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mark.rutland, acme, tglx, brueckner, torvalds,
alexander.shishkin, heiko.carstens, tmricht, schwidefsky,
linux-kernel, keescook, jolsa, hpa, linux-tip-commits
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Apr 10, 2019 at 05:13:54AM -0700, tip-bot for Peter Zijlstra wrote:
> > Commit-ID: 86071b11317550d994b55ce5e31aa06bcad783b5
> > Gitweb: https://git.kernel.org/tip/86071b11317550d994b55ce5e31aa06bcad783b5
> > Author: Peter Zijlstra <peterz@infradead.org>
> > AuthorDate: Thu, 4 Apr 2019 15:03:00 +0200
> > Committer: Ingo Molnar <mingo@kernel.org>
> > CommitDate: Wed, 10 Apr 2019 13:47:09 +0200
> >
> > perf/core: Fix perf_event_disable_inatomic() race
> >
> > Thomas-Mich Richter reported he triggered a WARN()ing from event_function_local()
> > on his s390. The problem boils down to:
> >
> > CPU-A CPU-B
> >
> > perf_event_overflow()
> > perf_event_disable_inatomic()
> > @pending_disable = 1
> > irq_work_queue();
> >
> > sched-out
> > event_sched_out()
> > @pending_disable = 0
> >
> > sched-in
> > perf_event_overflow()
> > perf_event_disable_inatomic()
> > @pending_disable = 1;
> > irq_work_queue(); // FAILS
> >
> > irq_work_run()
> > perf_pending_event()
> > if (@pending_disable)
> > perf_event_disable_local(); // WHOOPS
> >
> > The problem exists in generic, but s390 is particularly sensitive
> > because it doesn't implement arch_irq_work_raise(), nor does it call
> > irq_work_run() from it's PMU interrupt handler (nor would that be
> > sufficient in this case, because s390 also generates
> > perf_event_overflow() from pmu::stop). Add to that the fact that s390
> > is a virtual architecture and (virtual) CPU-A can stall long enough
> > for the above race to happen, even if it would self-IPI.
> >
> > Adding a irq_work_sync() to event_sched_in() would work for all hardare
> > PMUs that properly use irq_work_run() but fails for software PMUs.
> >
> > Instead encode the CPU number in @pending_disable, such that we can
> > tell which CPU requested the disable. This then allows us to detect
> > the above scenario and even redirect the IPI to make up for the failed
> > queue.
>
> Ingo, could you please fold in the below delta? It turns out I
> overlooked two insteances :-(
>
> --- a/kernel/events/ring_buffer.c
> +++ b/kernel/events/ring_buffer.c
> @@ -392,7 +392,7 @@ void *perf_aux_output_begin(struct perf_
> * store that will be enabled on successful return
> */
> if (!handle->size) { /* A, matches D */
> - event->pending_disable = 1;
> + event->pending_disable = smp_processor_id();
> perf_output_wakeup(handle);
> local_set(&rb->aux_nest, 0);
> goto err_put;
> @@ -480,7 +480,7 @@ void perf_aux_output_end(struct perf_out
>
> if (wakeup) {
> if (handle->aux_flags & PERF_AUX_FLAG_TRUNCATED)
> - handle->event->pending_disable = 1;
> + handle->event->pending_disable = smp_processor_id();
> perf_output_wakeup(handle);
> }
Sure, done!
Thanks,
Ingo
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-04-12 6:55 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <tip-86071b11317550d994b55ce5e31aa06bcad783b5@git.kernel.org>
2019-04-11 13:04 ` [tip:perf/urgent] perf/core: Fix perf_event_disable_inatomic() race Peter Zijlstra
2019-04-12 6:55 ` Ingo Molnar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).