linux-kernel - Re: [PATCH v3 0/7] thermal: processor

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:   Wed, 13 Sep 2023 10:15:26 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     srinivas pandruvada <srinivas.pandruvada@...ux.intel.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>, daniel.lezcano@...aro.org,
        rui.zhang@...el.com, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/7] thermal: processor_thermal: Suport workload hint

On Tue, Sep 12, 2023 at 9:44 PM srinivas pandruvada
<srinivas.pandruvada@...ux.intel.com> wrote:
>
> Hi Rafael,
>
> On Tue, 2023-09-12 at 16:09 +0200, Rafael J. Wysocki wrote:
> > On Tue, Aug 29, 2023 at 2:23 AM Srinivas Pandruvada
> > <srinivas.pandruvada@...ux.intel.com> wrote:
> > >
> > >
>
> [...]
>
> > > --
> >
> > There is a slight issue with the patch ordering in this series,
> > because the interface to enable the interrupt should only be provided
> > after implementing the interrupt handlers.  I don't think that anyone
> > will apply the series partially and try to enable the feature,
> > though.
> Thanks!
>
> >
> > Also, I'm not actually sure if proc_thermal_wt_intr_callback() can
> > run
> > safely against the work item scheduled in proc_thermal_irq_handler()
> > in case the workload hint one triggers along with a thermal threshold
> > one.  I think that the access to MMIO is cached, so what if they both
> > try to update the same cache line at the same time?  Or are they
> > guaranteed to be different cache lines?
> These two registers are 90 cache lines apart. Looking at all the
> registers on this bar for status offsets, they are several cache lines
> apart. Also this bar is non prefetchable, so continuous data can't be
> fetched ahead.

OK

> >
> > Anyway, tentatively applied as 6.7 material, but I've changed the
> > second patch somewhat, because I couldn't convince myself that the
> > implicit type conversions in
> > processor_thermal_mbox_interrupt_config()
> > would always do the right thing regardless of the numbers involved,
> > so
> > please check the result in my bleeding-edge branch.
> >
> If I diff, there is only one change in processor_thermal_mbox.c. Tested
> that change and works fine.

Good, thanks!