linux-kernel - Re: [PATCH 18/52] perf report: Add 'type' sort key

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: <ZV9WSdshxv9MZTb0@kernel.org>
Date:   Thu, 23 Nov 2023 10:40:25 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Namhyung Kim <namhyung@...nel.org>
Cc:     Jiri Olsa <jolsa@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ian Rogers <irogers@...gle.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Ingo Molnar <mingo@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-perf-users@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Stephane Eranian <eranian@...gle.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        linux-trace-devel@...r.kernel.org, linux-toolchains@...r.kernel.org
Subject: Re: [PATCH 18/52] perf report: Add 'type' sort key

Em Wed, Nov 22, 2023 at 01:13:04PM -0800, Namhyung Kim escreveu:
> On Wed, Nov 22, 2023 at 11:54 AM Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
> > Em Wed, Nov 22, 2023 at 10:49:13AM -0800, Namhyung Kim escreveu:
> > > On Tue, Nov 21, 2023 at 9:55 AM Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
> > > > ⬢[acme@...lbox perf-tools-next]$ perf report -s type
> > > > perf: Segmentation fault

> > > Right, the 'type' sort key was added here but unfortunately
> > > it's not ready for prime time yet.  It also needs the next patch
> > > 19/52 ("perf report: Support data type profiling") to fully enable
> > > the feature.  Do you think it's better to squash into here?

> > I haven't checked if squashing would be a good idea, but if you think
> > its the right granularity, then do it, as long as we can test features
> > in various ways as they are getting added, as I did, using a random
> > perf.data file.
 
> I still think it's better to split the change as it's logically separate.

The smaller the patches, the better, I'd say in general.

> But it's prematurely exposed then maybe needs some protection.

Yeah, that is what I felt like it needed, make it more robust by
checking if the used fields were properly initialized, etc.

- Arnaldo