| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <b721cfd3-8fb5-5225-1fb7-29b8cc85f417@linux.intel.com>
Date: Mon, 20 Jan 2020 11:50:16 -0500
From: "Liang, Kan" <kan.liang@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mingo@...nel.org, linux-kernel@...r.kernel.org, ak@...ux.intel.com,
like.xu@...ux.intel.com
Subject: Re: [PATCH] perf/x86/intel/ds: Fix x86_pmu_stop warning for large
PEBS
On 1/20/2020 5:50 AM, Peter Zijlstra wrote:
> On Mon, Jan 13, 2020 at 06:09:35AM -0800, kan.liang@...ux.intel.com wrote:
>> From: Kan Liang <kan.liang@...ux.intel.com>
>>
>> A warning as below may be triggered when sampling large PEBS.
>
>> [ 410.729822] WARNING: CPU: 0 PID: 16397 at arch/x86/events/core.c:1422
>> x86_pmu_stop+0x95/0xa0
>
>> For large PEBS, the PEBS buffer can be drained from either NMI handler
>> or !NMI e.g. context switch. Current implementation doesn't handle them
>> differently. For !nmi, perf also call the generic overflow handler for
>> the last PEBS record. That may trigger the interrupt throttle, and stop
>> the event. That's wrong.
>>
>> Here is an example for !NMI scenario, context switch.
>> Let's say the max_samples_per_tick is adjusted to 2 for some reason.
>> A context switch happens right after a NMI.
>> When an old task is scheduled out, it will drain the PEBS buffer, and
>> then delete the event.
>> When draining the PEBS buffer, perf_event_overflow() will be called for
>> the last PEBS record. Since the max_samples_per_tick is only 2, the
>> interrupt throttle must be triggered. The event will be stopped.
>> After the draining, the scheduler will delete the event, which stops the
>> event again. The warning is triggered.
>>
>> Perf should handle the NMI and !NMI differently for large PEBS.
>> For NMI, the generic overflow handler is required for the last PEBS
>> record.
>> But, for !NMI, there is no overflow. The generic overflow handler should
>> not be invoked. Perf should treat the last record exactly the same as
>> the rest of PEBS records.
>
> Hurmph. there's something there, but the above is hard to read.
>
It describes an example as below
//max_samples_per_tick is adjusted to 2
//NMI happens
intel_pmu_handle_irq()
handle_pmi_common()
drain_pebs()
__intel_pmu_pebs_event()
perf_event_overflow()
__perf_event_account_interrupt()
hwc->interrupts = 1
return 0
//A context switch right after the NMI.
//In the same tick, perf_throttled_seq is not changed.
perf_event_task_sched_out()
perf_pmu_sched_task()
intel_pmu_drain_pebs_buffer()
__intel_pmu_pebs_event()
perf_event_overflow()
__perf_event_account_interrupt()
++hwc->interrupts >= max_samples_per_tick
return 1
x86_pmu_stop(); # First stop
perf_event_context_sched_out()
task_ctx_sched_out()
ctx_sched_out()
event_sched_out()
x86_pmu_del()
x86_pmu_stop(); # Second stop and trigger the warning
> drain_pebs() is called from:
>
> - handle_pmi_common() -- sample context
> - intel_pmu_pebs_sched_task() -- non sample context
> - intel_pmu_pebs_disable() -- non sample context
> - intel_pmu_auto_reload_read() -- possible sample context
> > So the question is what to do for PERF_SAMPLE_READ + PERF_FORMAT_GROUP.
>
> I don't think throttling there is right either, but that does mean the
> simple in_nmi() test you use is wrong.
I'm not sure if it's accurate to call it sample/non sample context.
Because for large PEBS, it should always output samples here for any cases.
As my understanding, the sample context you mean is actually the same as
interrupt context.
- handle_pmi_common(): -- NMI
- intel_pmu_pebs_sched_task(): -- Can only be invoked in !NMI
- intel_pmu_pebs_disable(): -- Can only be invoked in !NMI
(I think there is only one case which the function will be called
in NMI, throttling triggered x86_pmu_stop(). For this case, the
PEBS buffer has been drained. __intel_pmu_pebs_event() will not
be touched.)
- intel_pmu_auto_reload_read(): Can only be invoked in NMI via
PERF_SAMPLE_READ. For other cases, it will be only invoked in !NMI.
The throttling here is to control the number of interrupts. In NMI
context, we should check the throttling. Otherwise, it's unnecessary.
I think the in_nmi() test should be enough here.
>
> Perhaps we can do something with how intel_pmu_drain_pebs_buffer()
> passes in dummy regs pointer to distinguish between the sample and non
> sample context.
>
>> ---
>> arch/x86/events/intel/ds.c | 23 +++++++++++++++--------
>> 1 file changed, 15 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
>> index 7c896d7e8b6c..51baff083938 100644
>> --- a/arch/x86/events/intel/ds.c
>> +++ b/arch/x86/events/intel/ds.c
>> @@ -1780,15 +1780,22 @@ static void __intel_pmu_pebs_event(struct perf_event *event,
>>
>> setup_sample(event, iregs, at, &data, regs);
>>
>> - /*
>> - * All but the last records are processed.
>> - * The last one is left to be able to call the overflow handler.
>> - */
>> - if (perf_event_overflow(event, &data, regs)) {
>> - x86_pmu_stop(event, 0);
>> - return;
>> + if (in_nmi()) {
>> + /*
>> + * All but the last records are processed.
>> + * The last one is left to be able to call the overflow handler.
>> + */
>> + if (perf_event_overflow(event, &data, regs))
>> + x86_pmu_stop(event, 0);
>> + } else {
>> + /*
>> + * For !NMI, e.g context switch, there is no overflow.
>> + * The generic overflow handler should not be invoked.
>> + * Perf should treat the last record exactly the same as the
>> + * rest of PEBS records.
>> + */
>> + perf_event_output(event, &data, regs);
>> }
>
> Maybe write it like so?
>
> diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
> index 4b94ae4ae369..b66be085c7a4 100644
> --- a/arch/x86/events/intel/ds.c
> +++ b/arch/x86/events/intel/ds.c
> @@ -1747,25 +1747,22 @@ static void __intel_pmu_pebs_event(struct perf_event *event,
> } else if (!intel_pmu_save_and_restart(event))
> return;
>
> - while (count > 1) {
> + while (count > /* cond */) {
What's cond?
Could you please elaborate?
Thanks,
Kan
> setup_sample(event, iregs, at, &data, regs);
> perf_event_output(event, &data, regs);
> at += cpuc->pebs_record_size;
> at = get_next_pebs_record_by_bit(at, top, bit);
> - count--;
> + if (!--count)
> + return; > }
>
> - setup_sample(event, iregs, at, &data, regs);
> -
> /*
> * All but the last records are processed.
> * The last one is left to be able to call the overflow handler.
> */
> - if (perf_event_overflow(event, &data, regs)) {
> + setup_sample(event, iregs, at, &data, regs);
> + if (perf_event_overflow(event, &data, regs))
> x86_pmu_stop(event, 0);
> - return;
> - }
> -
> }
>
> static void intel_pmu_drain_pebs_core(struct pt_regs *iregs)
>
Powered by blists - more mailing lists