linux-kernel - Re: [PATCH v3 1/8] thermal: core: Add mechanism for connecting trips with driver data

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: <CAJZ5v0gtkZTwt-qP0uwvTJNx8cpO1o1esmW9BfVxB67X3Yt++w@mail.gmail.com>
Date:   Thu, 3 Aug 2023 16:15:28 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Michal Wilczynski <michal.wilczynski@...el.com>,
        Zhang Rui <rui.zhang@...el.com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Subject: Re: [PATCH v3 1/8] thermal: core: Add mechanism for connecting trips
 with driver data

On Thu, Aug 3, 2023 at 3:06 PM Daniel Lezcano <daniel.lezcano@...aro.org> wrote:
>
> On 02/08/2023 18:48, Rafael J. Wysocki wrote:
>
> [ ... ]
>
> >> Let me check if I can do something on top of your series to move it in
> >> the ACPI driver.
> >
> > It doesn't need to be on top of my series, so if you have an idea,
> > please just let me know what it is.
> >
> > It can't be entirely in the ACPI driver AFAICS, though, because
> > trips[i] need to be modified on updates and they belong to the core.
> > Hence, the driver needs some help from the core to get to them.  It
> > can be something like "this is my trip tag and please give me the
> > address of the trip matching it" or similar, but it is needed, because
> > the driver has to assume that the trip indices used by it initially
> > may change.
>
> May be I'm missing something but driver_ref does not seems to be used
> except when assigning it, no?

It is used on the other side.  That is, the value assigned to the trip
field in it is accessed via trip_ref in the driver.

The idea is that the driver puts a pointer to its local struct
thermal_trip_ref into a struct thermal_trip and the core stores the
address of that struct thermal_trip in there, which allows the driver
to access the struct thermal_trip via its local struct
thermal_trip_ref going forward.

Admittedly, this is somewhat convoluted.

I have an alternative approach in the works, just for illustration
purposes if nothing else, but I have encountered a problem that I
would like to ask you about.

Namely, zone disabling is not particularly useful for preventing the
zone from being used while the trips are updated, because it has side
effects.  First, it triggers __thermal_zone_device_update() and a
netlink message every time the mode changes, which can be kind of
overcome.  But second, if the mode is "disabled", it does not actually
prevent things like __thermal_zone_get_trip() from running and the
zone lock is the only thing that can be used for that AFAICS.

So by "disabling" a thermal zone, did you mean changing its mode to
"disabled" or something else?