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: <dcafb275-40eb-4663-8ede-bf15546f83f6@linaro.org>
Date:   Thu, 12 Oct 2023 23:13:43 +0200
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Lukasz Luba <lukasz.luba@....com>,
        Thierry Reding <thierry.reding@...il.com>,
        Amit Kucheria <amitk@...nel.org>,
        Zhang Rui <rui.zhang@...el.com>,
        "open list:THERMAL" <linux-pm@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] thermal/core: Hardening the self-encapsulation

On 12/10/2023 19:44, Rafael J. Wysocki wrote:

[ ... ]

>> Yes, we should but there is the series for nvidia (pointed in the
>> changelog) which need a slight refresh for the bindings AFAIR. That
>> series is since March 2023 and Thierry seems busy [1]. I'm holding the
>> hardening since then.
>>
>> So I don't know how to make progress on this? I was assuming we can
>> merge this series and let the compiler recall what has to be fixed.
>>
>> [1] https://lore.kernel.org/all/ZK14edZUih1kH_sZ@orome/
>>
>> and as soon as it is fixed, we convert the WARNING to ERROR :P
> 
> To be honest, I'm not sure if anything needs to be done along the
> lines of this patch right now or even at all.
> 
> The only concern here would be that some new drivers would include
> thermal_core.h while we were waiting for the remaining existing
> abusers to be fixed, but since this hasn't happened for the last 6
> months, I'm not worried.
> 
> It would be good to add a notice to thermal_core.h that this file is
> for internal use in the thermal core only, though.

So this series will give a warning for the remaining nvidia driver but 
Thierry just send the changes to get rid of the thermal_core.h (Thanks!)

AFAICT, the last user of the thermal_zone_device structure is the 
int340x driver but the patch fixing the structure internal usage is 
already in the bleeding edge (well perhaps one nit is missing for the trace)

As soon as the bindings are acked, then I can pick the patches from 
Thierry which will end up in your tree. Then you can apply the current 
series. And finally I'll send the last patch moving the thermal zone 
device structure to the thermal_core.h. And we will be done with this part.

Having a compilation warning (I would prefer a more coercive error if we 
agree on that) will help to not have to double check every time 
thermal_core.h is not pulled in the drivers when patches are submitted.

-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ