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] [day] [month] [year] [list]
Message-ID: <CAP-5=fXdF41qVwUnZ1XjPM9PuiDa8owYwK=3eRznPEnMKrVkdw@mail.gmail.com>
Date: Tue, 4 Feb 2025 11:30:39 -0800
From: Ian Rogers <irogers@...gle.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>, Kan Liang <kan.liang@...ux.intel.com>, 
	Jiri Olsa <jolsa@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>, 
	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, 
	LKML <linux-kernel@...r.kernel.org>, linux-perf-users@...r.kernel.org, 
	Howard Chu <howardchu95@...il.com>
Subject: Re: [PATCH v2 1/4] perf trace: Allocate syscall stats only if summary
 is on

On Tue, Feb 4, 2025 at 11:21 AM Namhyung Kim <namhyung@...nel.org> wrote:
>
> On Tue, Feb 04, 2025 at 07:59:01AM -0800, Ian Rogers wrote:
> > On Mon, Feb 3, 2025 at 6:59 PM Namhyung Kim <namhyung@...nel.org> wrote:
> > >
> > > On Sat, Feb 01, 2025 at 10:57:00PM -0800, Ian Rogers wrote:
> > > > On Wed, Jan 29, 2025 at 7:05 PM Namhyung Kim <namhyung@...nel.org> wrote:
> > > > >
> > > > > The syscall stats are used only when summary is requested.  Let's avoid
> > > > > unnecessary operations.  Pass 'trace' pointer to check summary and give
> > > > > output file together.
> > > >
> > > > I don't think this last sentence makes sense.
> > >
> > > Thanks for your review.  I'd say:  Pass 'trace' pointer instead of doing
> > > 'summary' option and 'output' file pointer separately.
> >
> > This still doesn't make sense. There is lazier initialization:
> > ```
> > -               ttrace->syscall_stats = intlist__new(NULL);
> > +               if (trace->summary)
> > +                       ttrace->syscall_stats = intlist__new(NULL);
> > ```
> > and there are functions that take a FILE* but now we're going to use
> > the one in trace instead:
>
> Yep, those FILE* (fp) was from trace->output.
>
>
> > ```
> > @@ -1568,7 +1569,7 @@ static struct thread_trace *thread__trace(struct
> > thread *thread, FILE *fp)
> >
> >         return ttrace;
> >  fail:
> > -       color_fprintf(fp, PERF_COLOR_RED,
> > +       color_fprintf(trace->output, PERF_COLOR_RED,
> >                       "WARNING: not enough memory, dropping samples!\n");
> >         return NULL;
> > ```
> > So why does the one passed to trace still exist? Unfortunately names
> > like "fp" and "output" are not intention revealing.
>
> I think "fp" is a conventional name for file pointers (probably from
> K&R?).
>
> >
> > Anyway, from the commit message and the code I don't understand what
> > this change is trying to do.
>
> I don't know where you didn't get it.  Apparently my English is not good
> enough.  So this commit does two things.
>
> 1. check trace->summary before allocating syscall_stats
> 2. change signature of thread__trace from (thread, fp) to (thread,
>    trace) so that it can use trace->output (fp) and trace->summary.
>
> I thought the change #2 is trivial enough to be in the same commit.  But
> I can split that if you want.

Ah, the diff was showing the function signature still taking fp which
was confusing me. Looking above I see:
```
-static struct thread_trace *thread__trace(struct thread *thread, FILE *fp)
+static struct thread_trace *thread__trace(struct thread *thread,
struct trace *trace)
```
Keeping the context in trace and not splitting the patch both make
sense to me. It'd be nice to capture your more verbose description in
the commit message.

Thanks,
Ian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ