linux-kernel - RE: [PATCH v3] perf: arm_cspmu: Separate Arm and vendor module

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:   Tue, 6 Jun 2023 01:19:23 +0000
From:   Besar Wicaksono <bwicaksono@...dia.com>
To:     Robin Murphy <robin.murphy@....com>,
        "suzuki.poulose@....com" <suzuki.poulose@....com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will@...nel.org" <will@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>
CC:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        Thierry Reding <treding@...dia.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Vikram Sethi <vsethi@...dia.com>,
        Richard Wiley <rwiley@...dia.com>,
        Eric Funsten <efunsten@...dia.com>
Subject: RE: [PATCH v3] perf: arm_cspmu: Separate Arm and vendor module

Hi Robin,

> -----Original Message-----
> From: Robin Murphy <robin.murphy@....com>
> Sent: Thursday, June 1, 2023 9:34 AM
> To: Besar Wicaksono <bwicaksono@...dia.com>; suzuki.poulose@....com;
> catalin.marinas@....com; will@...nel.org; mark.rutland@....com
> Cc: linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; linux-
> tegra@...r.kernel.org; Thierry Reding <treding@...dia.com>; Jonathan
> Hunter <jonathanh@...dia.com>; Vikram Sethi <vsethi@...dia.com>; Richard
> Wiley <rwiley@...dia.com>; Eric Funsten <efunsten@...dia.com>
> Subject: Re: [PATCH v3] perf: arm_cspmu: Separate Arm and vendor module
> 
> External email: Use caution opening links or attachments
> 
> 
> On 2023-05-08 18:04, Besar Wicaksono wrote:
> [...]
> >>> +obj-$(CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU) +=
> >> arm_cspmu_impl.o
> >>
> >> Not sure what's up with this... I have no complaint with keeping the
> >> impl infrastucture together in its own source file, but it still wants
> >> to end up as part of arm_cspmu_module. Doing otherwise just adds
> >> unnecessary overhead at many levels and invites more problems.
> >
> > My intention is to separate arm_cspmu_impl, arm_cspmu, and
> > vendor backend into different modules. Here is the dependency I have in
> mind:
> >
> >                                                 arm_cspmu_impl
> >                                                       ____|____
> >                                                      |                  |
> >                                      arm_cspmu               nvidia_cspmu
> >
> > This helps during device probe that the call to request_module can be made
> > as a blocking call and the backend init_impl_ops will always be ready to use
> after
> > request_module returns. The code seems simpler this way. Could you please
> > elaborate the potential issue that might arise with this approach?
> 
> I see the intent; the main issue is that the implementation of it is
> needlessly fiddly: arm_cspmu_impl is not useful on its own, and probably
> only represents a few hundred bytes of code, so putting in a distinct
> .ko which needs to be loaded separately is a relatively massive waste of
> filesystem space and memory for what it is. Also if anything that
> dependency is the wrong way round anyway - arm_cspmu could provide
> generic PMU functionality just fine regardless of arm_cspmu_impl, but
> arm_cspmu_impl definitely has a logical and functional dependency on
> arm_cspmu in order to serve any user-visible purpose.
> 

Thank you for the explanation. I will move the impl code back to arm_cspmu source file.
With that, we no longer can load the backend module synchronously, so I will use the
deferred probe approach as you suggested before.

Thanks,
Besar