From: Ingo Molnar <mingo@kernel.org>
To: kernel-janitors@vger.kernel.org
Subject: [PATCH] perf/x86/intel/pt: Clean up error handling in pt_event_add()
Date: Thu, 16 Apr 2015 10:38:30 +0000 [thread overview]
Message-ID: <20150416103830.GB7847@gmail.com> (raw)
* Alexander Shishkin <alexander.shishkin@linux.intel.com> wrote:
> Dan Carpenter <dan.carpenter@oracle.com> writes:
>
> > That's not the style that the rest of this file uses. Every function
> > uses direct returns where possible except pt_event_add() and that
> > function seems buggy.
>
> Indeed.
>
> > arch/x86/kernel/cpu/perf_event_intel_pt.c
> > 1000
> > 1001 if (mode & PERF_EF_START) {
> > 1002 pt_event_start(event, 0);
> > 1003 if (hwc->state = PERF_HES_STOPPED) {
> > 1004 pt_event_del(event, 0);
> > 1005 ret = -EBUSY;
> > ^^^^^^^^^^^^
> > We set "ret" here but then return zero.
> >
> > 1006 }
> > 1007 } else {
> > 1008 hwc->state = PERF_HES_STOPPED;
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Shouldn't we set "ret" here?
>
> No, or we'll end up returning -EBUSY where we should return zero for
> snapshot counters. It can be done above the quoted if statement.
>
> How does the following look to you?
>
> From 726515f8bbef2ca02c495695b9451533d1bc6207 Mon Sep 17 00:00:00 2001
> From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Date: Wed, 15 Apr 2015 12:56:52 +0300
> Subject: [PATCH] perf/x86/intel/pt: cleanup error paths in pt_event_add()
>
> pt_event_add() ends up returning 0 instead of -EBUSY in case of failure
> to start the newly added event. This is a result of complex handling of
> its return code.
>
> This patch makes the return code handling of pt_event_add() more obvious
> and fixes the mentioned bug.
So it's still not obvious enough IMO - I wrote the patch below.
Untested.
NOTE: I materially changed the existing clean up logic in the
pt_event_start() failure case to use the direct perf_aux_output_end()
path, not pt_event_del(). I could not convince myself that
pt_event_del() is really needed there - but I might be wrong.
In any case, these functions are a mess and they are barely
documented! Please add proper comments about what the interaction and
expected rules of perf_aux_output_begin(), pt_buffer_reset_offsets(),
pt_buffer_reset_markers(), pt_event_start(), perf_aux_output_end() et
al is, right now it's a guessing game mostly. (in a separate patch
please)
Btw., pt_event_start() has weird error handling as well: it should
probably return an error code, instead of open coding event->hw.state
= PERF_HES_STOPPED. This would have to be changed in all PMU drivers,
with core perf setting hw.state to PERF_HES_STOPPED or so?
Thanks,
Ingo
---
arch/x86/kernel/cpu/perf_event_intel_pt.c | 32 +++++++++++++++----------------
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_pt.c b/arch/x86/kernel/cpu/perf_event_intel_pt.c
index f2770641c0fd..1b298caf09c1 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_pt.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_pt.c
@@ -988,38 +988,36 @@ static int pt_event_add(struct perf_event *event, int mode)
int ret = -EBUSY;
if (pt->handle.event)
- goto out;
+ goto fail;
buf = perf_aux_output_begin(&pt->handle, event);
- if (!buf) {
- ret = -EINVAL;
- goto out;
- }
+ ret = -EINVAL;
+ if (!buf)
+ goto fail_stop;
pt_buffer_reset_offsets(buf, pt->handle.head);
if (!buf->snapshot) {
ret = pt_buffer_reset_markers(buf, &pt->handle);
- if (ret) {
- perf_aux_output_end(&pt->handle, 0, true);
- goto out;
- }
+ if (ret)
+ goto fail_end_stop;
}
if (mode & PERF_EF_START) {
pt_event_start(event, 0);
- if (hwc->state = PERF_HES_STOPPED) {
- pt_event_del(event, 0);
- ret = -EBUSY;
- }
+ ret = -EBUSY;
+ if (hwc->state = PERF_HES_STOPPED)
+ goto fail_end_stop;
} else {
hwc->state = PERF_HES_STOPPED;
}
- ret = 0;
-out:
+ return 0;
- if (ret)
- hwc->state = PERF_HES_STOPPED;
+fail_end_stop:
+ perf_aux_output_end(&pt->handle, 0, true);
+fail_stop:
+ hwc->state = PERF_HES_STOPPED;
+fail:
return ret;
}
next reply other threads:[~2015-04-16 10:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 10:38 Ingo Molnar [this message]
2015-04-17 15:06 ` [PATCH] perf/x86/intel/pt: Clean up error handling in pt_event_add() Alexander Shishkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150416103830.GB7847@gmail.com \
--to=mingo@kernel.org \
--cc=kernel-janitors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox