linux-kernel - Re: [PATCH] hwmon: Fix WARN_ON() always called from devm_hwmon_device

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: <48665660-5cca-4d92-a2b8-cf633ac632a6@roeck-us.net>
Date: Fri, 13 Sep 2024 07:28:10 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: PJ Waskiewicz <ppwaskie@...nel.org>, Matthew Sanders <m@...ande.rs>,
 jdelvare@...e.com, linux-hwmon@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hwmon: Fix WARN_ON() always called from
 devm_hwmon_device_unregister()

On 9/12/24 23:40, PJ Waskiewicz wrote:
> On Thu, 2024-09-12 at 07:13 -0700, Guenter Roeck wrote:
>> On 9/12/24 02:14, Matthew Sanders wrote:
>>> devm_hwmon_device_unregister() only takes parent of a devres-
>>> managed
>>> hwmon device as an argument. This always fails, as devres can't
>>> find
>>> the hwmon device it needs to unregister with the parent device
>>> alone.
>>> Without this patch, the WARN_ON() in devm_hwmon_device_unregister()
>>> will
>>> always be displayed unconditionally:
>>>
>>> [    7.969746] WARNING: CPU: 1 PID: 224 at
>>> drivers/hwmon/hwmon.c:1205 devm_hwmon_device_unregister+0x28/0x30
>>>
>>> This patch adds an extra argument to
>>> devm_hwmon_device_unregister(), a
>>> pointer to a hwmon device which was previously registered to the
>>> parent using devres.
>>>
>>> There aren't any drivers which currently make use of this function,
>>> so
>>> any existing users of devm_hwmon_* shouldn't require any changes as
>>> a
>>> result of this patch.
>>
>> If there are no users, there is no need to keep the function. We
>> should drop
>> it instead.
> 
> There aren't any direct in-tree users of the function.  But some out-
> of-tree drivers can find it useful to use, hence Matt hitting this
> issue.
> 
> If there's a desire to just remove it, that's fine.  But it would
> remove a handy hook for out-of-tree stuff.
> 

Any use of this function is most likely wrong. Out-of-tree code is
completely irrelevant for the upstream kernel. On the contrary - it
is another reason for removing this function. I'll do that myself.

Guenter