linux-kernel - Re: [PATCH v2 00/27] Constify tool pointers

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]

Date: Fri, 28 Jun 2024 15:07:58 -0700
From: Namhyung Kim <namhyung@...nel.org>
To: Ian Rogers <irogers@...gle.com>
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>, 
	John Garry <john.g.garry@...cle.com>, Will Deacon <will@...nel.org>, 
	James Clark <james.clark@....com>, Mike Leach <mike.leach@...aro.org>, Leo Yan <leo.yan@...ux.dev>, 
	Suzuki K Poulose <suzuki.poulose@....com>, Yicong Yang <yangyicong@...ilicon.com>, 
	Jonathan Cameron <jonathan.cameron@...wei.com>, Nick Terrell <terrelln@...com>, 
	Nick Desaulniers <ndesaulniers@...gle.com>, Oliver Upton <oliver.upton@...ux.dev>, 
	Anshuman Khandual <anshuman.khandual@....com>, Song Liu <song@...nel.org>, 
	Ilkka Koskinen <ilkka@...amperecomputing.com>, Huacai Chen <chenhuacai@...nel.org>, 
	Yanteng Si <siyanteng@...ngson.cn>, Sun Haiyong <sunhaiyong@...ngson.cn>, 
	linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 00/27] Constify tool pointers

On Fri, Jun 28, 2024 at 10:52 AM Ian Rogers <irogers@...gle.com> wrote:
>
> On Fri, Jun 28, 2024 at 10:25 AM Namhyung Kim <namhyung@...nel.org> wrote:
> >
> > On Wed, Jun 26, 2024 at 01:36:02PM -0700, Ian Rogers wrote:
> > > struct perf_tool provides a set of function pointers that are called
> > > through when processing perf data. To make filling the pointers less
> > > cumbersome, if they are NULL perf_tools__fill_defaults will add
> > > default do nothing implementations.
> > >
> > > This change refactors struct perf_tool to have an init function that
> > > provides the default implementation. The special use of NULL and
> > > perf_tools__fill_defaults are removed. As a consequence the tool
> > > pointers can then all be made const, which better reflects the
> > > behavior a particular perf command would expect of the tool and to
> > > some extent can reduce the cognitive load on someone working on a
> > > command.
> >
> > I thought you actually wanted to make the tool const (rodata) but it
> > seems you leave it as is but treat it as const.
>
> So I think that is a next step on top of these changes but it would
> need something a bit special as we want to default initialize some
> fields but then initialize others. Something like (which wouldn't
> work):
>
> .tool = DEFAULT_TOOL_STUBS({
>                .sample         = process_sample_event,
>                .fork           = perf_event__process_fork,
>                .exit           = perf_event__process_exit,
>                .comm           = perf_event__process_comm,
>                .namespaces     = perf_event__process_namespaces,
>                .mmap           = build_id__process_mmap,
>                .mmap2          = build_id__process_mmap2,
>                .itrace_start   = process_timestamp_boundary,
>                .aux            = process_timestamp_boundary})
>
> Being const is just saying hey all these event callbacks aren't going
> to mutate the tool, something I wanted to rule out as part of a change
> I'm working on.
>
> > I'm curious if we can change the event delivery code something like:
> >
> >   if (tool->func)
> >       tool->func(...);
> >   else
> >       stub_func(...);
> >
> > Then probably we don't need to touch the tool and make it const.
> > Thoughts?
>
> It works but the approach needs to change all tool func callers. I
> think it is also more obvious as an API to have a default value and
> override it, rather than giving special properties to NULL that
> callers should adhere to - we're doing a kind of poor man's virtual
> method dispatch and you wouldn't typically expect a NULL check as part
> of that.

I guess we only have a few callers in util/session.c.

Thanks,
Namhyung