linux-kernel - Re: [PATCH] perf/core: move all of the pmu devices into their own location

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=fUCDA1YLDrMgMpr=o4ESFey1b51+DfBwCF+cG7+-yidwg@mail.gmail.com>
Date: Wed, 5 Feb 2025 08:48:21 -0800
From: Ian Rogers <irogers@...gle.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...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>, "Liang, Kan" <kan.liang@...ux.intel.com>
Subject: Re: [PATCH] perf/core: move all of the pmu devices into their own location

On Tue, Feb 4, 2025 at 9:41 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> On Tue, Feb 04, 2025 at 10:17:17AM -0800, Ian Rogers wrote:
> > On Mon, Feb 3, 2025 at 11:05 PM Greg Kroah-Hartman
> > <gregkh@...uxfoundation.org> wrote:
> > >
> > > On Mon, Feb 03, 2025 at 11:44:13AM -0800, Ian Rogers wrote:
> > > > On Mon, Feb 3, 2025 at 11:25 AM Greg Kroah-Hartman
> > > > <gregkh@...uxfoundation.org> wrote:
> > [snip]
> > > > > Note, if you all don't like "pmu_bus" for the name, that's fine, please
> > > > > let me know and I can rename it to something else, but it should be
> > > > > something to get these objects out of the root sysfs directory.
> > > >
> > > > Excuse my ignorance, does the event_source bus already provide a
> > > > similar solution?
> > > > ```
> > > > $ ls /sys/bus/event_source/devices
> > > > breakpoint   i915       msr         uncore_arb     uncore_cbox_3
> > > > uncore_cbox_7              uprobe
> > > > cpu          intel_bts  power       uncore_cbox_0  uncore_cbox_4  uncore_clock
> > > > cstate_core  intel_pt   software    uncore_cbox_1  uncore_cbox_5
> > > > uncore_imc_free_running_0
> > > > cstate_pkg   kprobe     tracepoint  uncore_cbox_2  uncore_cbox_6
> > > > uncore_imc_free_running_1
> > > > $ ls /sys/devices
> > > > breakpoint   intel_pt     platform    uncore_arb     uncore_cbox_5
> > > >          uprobe
> > > > cpu          isa          pnp0        uncore_cbox_0  uncore_cbox_6
> > > >          virtual
> > > > cstate_core  kprobe       power       uncore_cbox_1  uncore_cbox_7
> > > > cstate_pkg   LNXSYSTM:00  software    uncore_cbox_2  uncore_clock
> > > > i915         msr          system      uncore_cbox_3  uncore_imc_free_running_0
> > > > intel_bts    pci0000:00   tracepoint  uncore_cbox_4  uncore_imc_free_running_1
> > > > ```
> > >
> > > Those are the exact same device structures :)
> > >
> > > Look at /sys/bus/event_source/devices/ those are symlinks back to
> > > /sys/devices.  In other words, that's the exact same structures, and
> > > the mess in /sys/devices/ with these event devices is what I am trying
> > > to clean up.
> >
> > Thanks! Again my ignorance, why do we need pmu_bus?
>
> You need some sort of "bus" to group all of your devices on.  It could
> also be a class, your call.  This is how the driver model in the kernel
> works.

Sure, I wasn't clear how this mapped out in sysfs.

> > Could the symlinks in event_source be the actual devices?
>
> That's not how the driver model works.

Ok, so I guess that's what's confusing me. Where will the new devices
be in sysfs? If it is /sys/bus/pmu_bus then why is
/sys/bus/event_source a different case? I guess I should read docs and
the source :-)

> > Perhaps for temporary compatibility some symlinks could be placed in
> > /sys/devices?
>
> No, /sys/devices/ is never guaranteed to have stable placement.
>
> And define "temporary" :)

I need to finish my time machine to resolve issues like this :-) An
unfortunate thing with the PMU acronym is that it is overloaded and
can mean Power Management Unit. Events and perf are other names used
in the code and they don't seem overloaded, but it isn't clear to me
we care about the name being overloaded. I'm afflicted by thinking of
Digital Rights Management every time I hear DRM.

Thanks,
Ian

> thanks,
>
> greg k-h