linux-kernel - Re: [PATCH v7 01/16] perf python: Add more exceptions on error paths

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAP-5=fWQQoo9OQhiQEyAGvUm-LVs7vpkbvEdnw7OO+KGBXiHqA@mail.gmail.com>
Date: Wed, 23 Jul 2025 11:21:18 -0700
From: Ian Rogers <irogers@...gle.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Arnaldo Carvalho de Melo <acme@...nel.org>, Mark Rutland <mark.rutland@....com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, 
	Adrian Hunter <adrian.hunter@...el.com>, Kan Liang <kan.liang@...ux.intel.com>, 
	James Clark <james.clark@...aro.org>, Xu Yang <xu.yang_2@....com>, 
	"Masami Hiramatsu (Google)" <mhiramat@...nel.org>, Collin Funk <collin.funk1@...il.com>, 
	Howard Chu <howardchu95@...il.com>, Weilin Wang <weilin.wang@...el.com>, 
	Andi Kleen <ak@...ux.intel.com>, "Dr. David Alan Gilbert" <linux@...blig.org>, 
	Thomas Richter <tmricht@...ux.ibm.com>, Tiezhu Yang <yangtiezhu@...ngson.cn>, 
	Gautam Menghani <gautam@...ux.ibm.com>, Thomas Falcon <thomas.falcon@...el.com>, 
	Chun-Tse Shao <ctshao@...gle.com>, linux-kernel@...r.kernel.org, 
	linux-perf-users@...r.kernel.org
Subject: Re: [PATCH v7 01/16] perf python: Add more exceptions on error paths

On Wed, Jul 23, 2025 at 11:13 AM Namhyung Kim <namhyung@...nel.org> wrote:
>
> On Mon, Jul 14, 2025 at 09:43:49AM -0700, Ian Rogers wrote:
> > Returning NULL will cause the python interpreter to fail but not
> > report an error. If none wants to be returned then Py_None needs
> > returning. Set the error for the cases returning NULL so that more
> > meaningful interpreter behavior is had.
>
> It looks like you are adding error messages for the failure cases, not
> adding new exceptions, right?  IIUC returning NULL in pyrf_event__new()
> ends up having PyErr_NoMemory().  Then now it has different messages?

This change doesn't alter the exception if there already is one. There
are lots of cases where NULL is being returned for an error but that
causes the python interpreter to fail/crash. This patch is just adding
the exceptions and still returning NULL, previously set exceptions are
left alone. With the exceptions returned the python interpreter does
something more useful than fail/crash :-)

> >
> > Signed-off-by: Ian Rogers <irogers@...gle.com>
> > ---
> >  tools/perf/util/python.c | 14 +++++++++++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
> > index 2f28f71325a8..02544387f39d 100644
> > --- a/tools/perf/util/python.c
> > +++ b/tools/perf/util/python.c
> > @@ -475,13 +475,19 @@ static PyObject *pyrf_event__new(const union perf_event *event)
> >       if ((event->header.type < PERF_RECORD_MMAP ||
> >            event->header.type > PERF_RECORD_SAMPLE) &&
> >           !(event->header.type == PERF_RECORD_SWITCH ||
> > -           event->header.type == PERF_RECORD_SWITCH_CPU_WIDE))
> > +           event->header.type == PERF_RECORD_SWITCH_CPU_WIDE)){
> > +             PyErr_Format(PyExc_TypeError, "Unexpected header type %u",
> > +                          event->header.type);
> >               return NULL;
> > +     }
> >
> >       // FIXME this better be dynamic or we need to parse everything
> >       // before calling perf_mmap__consume(), including tracepoint fields.
> > -     if (sizeof(pevent->event) < event->header.size)
> > +     if (sizeof(pevent->event) < event->header.size) {
> > +             PyErr_Format(PyExc_TypeError, "Unexpected event version: %zd < %u",
>
> Maybe "Unexpected event size" instead?

I think size is more accurate to the code, version is more useful to
the user. I believe there is existing use of the event size being used
as a quasi version number, so I think this description is consistent.
If you feel strongly I can change it.

Thanks,
Ian

> Thanks,
> Namhyung
>
>
> > +                          sizeof(pevent->event), event->header.size);
> >               return NULL;
> > +     }
> >
> >       ptype = pyrf_event__type[event->header.type];
> >       pevent = PyObject_New(struct pyrf_event, ptype);
> > @@ -1199,8 +1205,10 @@ static PyObject *pyrf_evlist__read_on_cpu(struct pyrf_evlist *pevlist,
> >               return NULL;
> >
> >       md = get_md(evlist, cpu);
> > -     if (!md)
> > +     if (!md) {
> > +             PyErr_Format(PyExc_TypeError, "Unknown CPU '%d'", cpu);
> >               return NULL;
> > +     }
> >
> >       if (perf_mmap__read_init(&md->core) < 0)
> >               goto end;
> > --
> > 2.50.0.727.gbf7dc18ff4-goog
> >