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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAP-5=fXQ3nFZQRMTd+7wp2jEecRt2ykJ57oBO2=qqbnEeyQRvA@mail.gmail.com>
Date: Fri, 28 Jun 2024 10:52:06 -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>, 
	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: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.

Thanks,
Ian

> Thanks,
> Namhyung