Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Oct 12, 2021
    • Yang Yingliang's avatar
      hwmon: Fix possible memleak in __hwmon_device_register() · ada61aa0
      Yang Yingliang authored 
      
I got memory leak as follows when doing fault injection test:

unreferenced object 0xffff888102740438 (size 8):
  comm "27", pid 859, jiffies 4295031351 (age 143.992s)
  hex dump (first 8 bytes):
    68 77 6d 6f 6e 30 00 00                          hwmon0..
  backtrace:
    [<00000000544b5996>] __kmalloc_track_caller+0x1a6/0x300
    [<00000000df0d62b9>] kvasprintf+0xad/0x140
    [<00000000d3d2a3da>] kvasprintf_const+0x62/0x190
    [<000000005f8f0f29>] kobject_set_name_vargs+0x56/0x140
    [<00000000b739e4b9>] dev_set_name+0xb0/0xe0
    [<0000000095b69c25>] __hwmon_device_register+0xf19/0x1e50 [hwmon]
    [<00000000a7e65b52>] hwmon_device_register_with_info+0xcb/0x110 [hwmon]
    [<000000006f181e86>] devm_hwmon_device_register_with_info+0x85/0x100 [hwmon]
    [<0000000081bdc567>] tmp421_probe+0x2d2/0x465 [tmp421]
    [<00000000502cc3f8>] i2c_device_probe+0x4e1/0xbb0
    [<00000000f90bda3b>] really_probe+0x285/0xc30
    [<000000007eac7b77>] __driver_probe_device+0x35f/0x4f0
    [<000000004953d43d>] driver_probe_device+0x4f/0x140
    [<000000002ada2d41>] __device_attach_driver+0x24c/0x330
    [<00000000b3977977>] bus_for_each_drv+0x15d/0x1e0
    [<000000005bf2a8e3>] __device_attach+0x267/0x410

When device_register() returns an error, the name allocated in
dev_set_name() will be leaked, the put_device() should be used
instead of calling hwmon_dev_release() to give up the device
reference, then the name will be freed in kobject_cleanup().

Reported-by: default avatarHulk Robot <hulkci@huawei.com>
Fixes: bab2243c ("hwmon: Introduce hwmon_device_register_with_groups")
Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20211012112758.2681084-1-yangyingliang@huawei.com


Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      ada61aa0
  3. Jun 24, 2021
    • Dmitry Osipenko's avatar
      hwmon: Support set_trips() of thermal device ops · a5f6c0f8
      Dmitry Osipenko authored 
      
Support set_trips() callback of thermal device ops. This allows HWMON
device to operatively notify thermal core about temperature changes, which
is very handy to have in a case where HWMON sensor is used by CPU thermal
zone that performs passive cooling and emergency shutdown on overheat.
Thermal core will be able to react faster to temperature changes.

The set_trips() callback is entirely optional. If HWMON sensor doesn't
support setting thermal trips, then the callback is a NO-OP. The dummy
callback has no effect on the thermal core. The temperature trips are
either complement the temperature polling mechanism of thermal core or
replace the polling if sensor can set the trips and polling is disabled
by a particular device in a device-tree.

Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20210623042231.16008-3-digetx@gmail.com


Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      a5f6c0f8
  5. Apr 20, 2021
  7. Sep 23, 2020
  9. May 28, 2020
    • Guenter Roeck's avatar
      hwmon: Add notification support · 1597b374
      Guenter Roeck authored 
      
For hwmon drivers using the hwmon_device_register_with_info() API, it
is desirable to have a generic notification mechanism available. This
mechanism can be used to notify userspace as well as the thermal
subsystem if the driver experiences any events, such as warning or
critical alarms.

Implement hwmon_notify_event() to provide this mechanism. The function
generates a sysfs event and a udev event. If the device is registered
with the thermal subsystem and the event is associated with a temperature
sensor, also notify the thermal subsystem that a thermal event occurred.

Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
Signed-off-by: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      1597b374
  11. May 22, 2020
  13. Jan 23, 2020
  15. Jan 17, 2020
    • Guenter Roeck's avatar
      hwmon: (core) Do not use device managed functions for memory allocations · 3bf8bdcf
      Guenter Roeck authored 
      
The hwmon core uses device managed functions, tied to the hwmon parent
device, for various internal memory allocations. This is problematic
since hwmon device lifetime does not necessarily match its parent's
device lifetime. If there is a mismatch, memory leaks will accumulate
until the parent device is released.

Fix the problem by managing all memory allocations internally. The only
exception is memory allocation for thermal device registration, which
can be tied to the hwmon device, along with thermal device registration
itself.

Fixes: d560168b ("hwmon: (core) New hwmon registration API")
Cc: stable@vger.kernel.org # v4.14.x: 47c332de: hwmon: Deal with errors from the thermal subsystem
Cc: stable@vger.kernel.org # v4.14.x: 74e35127: hwmon: (core) Fix double-free in __hwmon_device_register()
Cc: stable@vger.kernel.org # v4.9.x: 3a412d5e: hwmon: (core) Simplify sysfs attribute name allocation
Cc: stable@vger.kernel.org # v4.9.x: 47c332de: hwmon: Deal with errors from the thermal subsystem
Cc: stable@vger.kernel.org # v4.9.x: 74e35127: hwmon: (core) Fix double-free in __hwmon_device_register()
Cc: stable@vger.kernel.org # v4.9+
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      3bf8bdcf
  17. Jun 24, 2019
    • Guenter Roeck's avatar
      hwmon: (core) Add comment describing how hwdev is freed in error path · 792eac18
      Guenter Roeck authored 
      
The hwmon core registers the hwmon device before adding sensors to the
thermal core. If that fails, the hwmon device is released and an error
is returned to the caller. From the code flow, it appears to be necessary
to free struct hwmon_device *, allocated with kzalloc(), in that
situation. This is incorrect, since the data structure will be freed
automatically in hwmon_dev_release() when device_unregister() is called.
This used to result in a double free, which was found and fixed with
commit 74e35127 ("hwmon: (core) Fix double-free in
__hwmon_device_register()"). This is, however, not obvious; any reader
may erroneously conclude that the data structure is not freed.

Add comment explaining why kfree() is not necessary in this situation.

Reported-by: default avatarEduardo Valentin <eduval@amazon.com>
Cc: Eduardo Valentin <eduval@amazon.com>
Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      792eac18
  19. Jun 06, 2019
    • Eduardo Valentin's avatar
      hwmon: (core) add thermal sensors only if dev->of_node is present · c41dd48e
      Eduardo Valentin authored 
      
Drivers may register to hwmon and request for also registering
with the thermal subsystem (HWMON_C_REGISTER_TZ). However,
some of these driver, e.g. marvell phy, may be probed from
Device Tree or being dynamically allocated, and in the later
case, it will not have a dev->of_node entry.

Registering with hwmon without the dev->of_node may result in
different outcomes depending on the device tree, which may
be a bit misleading. If the device tree blob has no 'thermal-zones'
node, the *hwmon_device_register*() family functions are going
to gracefully succeed, because of-thermal,
*thermal_zone_of_sensor_register() return -ENODEV in this case,
and the hwmon error path handles this error code as success to
cover for the case where CONFIG_THERMAL_OF is not set.
However, if the device tree blob has the 'thermal-zones'
entry, the *hwmon_device_register*() will always fail on callers
with no dev->of_node, propagating -EINVAL.

If dev->of_node is not present, calling of-thermal does not
make sense. For this reason, this patch checks first if the
device has a of_node before going over the process of registering
with the thermal subsystem of-thermal interface. And in this case,
when a caller of *hwmon_device_register*() with HWMON_C_REGISTER_TZ
and no dev->of_node will still register with hwmon, but not with
the thermal subsystem. If all the hwmon part bits are in place,
the registration will succeed.

Fixes: d560168b ("hwmon: (core) New hwmon registration API")
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: default avatarEduardo Valentin <eduval@amazon.com>
Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      c41dd48e
  21. Jun 05, 2019
  23. May 06, 2019
    • Daniel Lezcano's avatar
      hwmon/drivers/core: Simplify complex dependency · f3735332
      Daniel Lezcano authored 
      
As the thermal framework does not longer compile as a module, we can
simplify this condition below:

 if IS_REACHABLE(CONFIG_THERMAL) && defined(CONFIG_THERMAL_OF) && \
       (!defined(CONFIG_THERMAL_HWMON) || \
        !(defined(MODULE) && IS_MODULE(CONFIG_THERMAL)))

 if IS_REACHABLE(CONFIG_THERMAL) && defined(CONFIG_THERMAL_OF) && \
       (!defined(CONFIG_THERMAL_HWMON) || \
        !(defined(MODULE) && 0))

=> (whatever && 0) = 0

 if IS_REACHABLE(CONFIG_THERMAL) && defined(CONFIG_THERMAL_OF) && \
       (!defined(CONFIG_THERMAL_HWMON) || !(0))

 if IS_REACHABLE(CONFIG_THERMAL) && defined(CONFIG_THERMAL_OF) && \
       (!defined(CONFIG_THERMAL_HWMON) || 1)

=> (whatever || 1) = 1

 if IS_REACHABLE(CONFIG_THERMAL) && defined(CONFIG_THERMAL_OF) && \
       (1)

=> (whatever && 1) = whatever

 if IS_REACHABLE(CONFIG_THERMAL) && defined(CONFIG_THERMAL_OF)

CONFIG_THERMAL can not be a module anymore, then:

 if defined(CONFIG_THERMAL) && defined(CONFIG_THERMAL_OF)

And CONFIG_THERMAL_OF already depends on CONFIG_THERMAL, so:

 if defined(CONFIG_THERMAL_OF)

Thus,

 ifdef CONFIG_THERMAL_OF

Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: default avatarGuenter Roeck <linux@roeck-us.net>
Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      f3735332
  25. Apr 16, 2019
  27. Feb 18, 2019
  29. Dec 03, 2018
  31. Nov 04, 2018
    • Dmitry Osipenko's avatar
      hwmon: (core) Fix double-free in __hwmon_device_register() · 74e35127
      Dmitry Osipenko authored 
      
Fix double-free that happens when thermal zone setup fails, see KASAN log
below.

==================================================================
BUG: KASAN: double-free or invalid-free in __hwmon_device_register+0x5dc/0xa7c

CPU: 0 PID: 132 Comm: kworker/0:2 Tainted: G    B             4.19.0-rc8-next-20181016-00042-gb52cd80401e9-dirty #41
Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
Workqueue: events deferred_probe_work_func
Backtrace:
[<c0110540>] (dump_backtrace) from [<c0110944>] (show_stack+0x20/0x24)
[<c0110924>] (show_stack) from [<c105cb08>] (dump_stack+0x9c/0xb0)
[<c105ca6c>] (dump_stack) from [<c02fdaec>] (print_address_description+0x68/0x250)
[<c02fda84>] (print_address_description) from [<c02fd4ac>] (kasan_report_invalid_free+0x68/0x88)
[<c02fd444>] (kasan_report_invalid_free) from [<c02fc85c>] (__kasan_slab_free+0x1f4/0x200)
[<c02fc668>] (__kasan_slab_free) from [<c02fd0c0>] (kasan_slab_free+0x14/0x18)
[<c02fd0ac>] (kasan_slab_free) from [<c02f9c6c>] (kfree+0x90/0x294)
[<c02f9bdc>] (kfree) from [<c0b41bbc>] (__hwmon_device_register+0x5dc/0xa7c)
[<c0b415e0>] (__hwmon_device_register) from [<c0b421e8>] (hwmon_device_register_with_info+0xa0/0xa8)
[<c0b42148>] (hwmon_device_register_with_info) from [<c0b42324>] (devm_hwmon_device_register_with_info+0x74/0xb4)
[<c0b422b0>] (devm_hwmon_device_register_with_info) from [<c0b4481c>] (lm90_probe+0x414/0x578)
[<c0b44408>] (lm90_probe) from [<c0aeeff4>] (i2c_device_probe+0x35c/0x384)
[<c0aeec98>] (i2c_device_probe) from [<c08776cc>] (really_probe+0x290/0x3e4)
[<c087743c>] (really_probe) from [<c0877a2c>] (driver_probe_device+0x80/0x1c4)
[<c08779ac>] (driver_probe_device) from [<c0877da8>] (__device_attach_driver+0x104/0x11c)
[<c0877ca4>] (__device_attach_driver) from [<c0874dd8>] (bus_for_each_drv+0xa4/0xc8)
[<c0874d34>] (bus_for_each_drv) from [<c08773b0>] (__device_attach+0xf0/0x15c)
[<c08772c0>] (__device_attach) from [<c0877e24>] (device_initial_probe+0x1c/0x20)
[<c0877e08>] (device_initial_probe) from [<c08762f4>] (bus_probe_device+0xdc/0xec)
[<c0876218>] (bus_probe_device) from [<c0876a08>] (deferred_probe_work_func+0xa8/0xd4)
[<c0876960>] (deferred_probe_work_func) from [<c01527c4>] (process_one_work+0x3dc/0x96c)
[<c01523e8>] (process_one_work) from [<c01541e0>] (worker_thread+0x4ec/0x8bc)
[<c0153cf4>] (worker_thread) from [<c015b238>] (kthread+0x230/0x240)
[<c015b008>] (kthread) from [<c01010bc>] (ret_from_fork+0x14/0x38)
Exception stack(0xcf743fb0 to 0xcf743ff8)
3fa0:                                     00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000

Allocated by task 132:
 kasan_kmalloc.part.1+0x58/0xf4
 kasan_kmalloc+0x90/0xa4
 kmem_cache_alloc_trace+0x90/0x2a0
 __hwmon_device_register+0xbc/0xa7c
 hwmon_device_register_with_info+0xa0/0xa8
 devm_hwmon_device_register_with_info+0x74/0xb4
 lm90_probe+0x414/0x578
 i2c_device_probe+0x35c/0x384
 really_probe+0x290/0x3e4
 driver_probe_device+0x80/0x1c4
 __device_attach_driver+0x104/0x11c
 bus_for_each_drv+0xa4/0xc8
 __device_attach+0xf0/0x15c
 device_initial_probe+0x1c/0x20
 bus_probe_device+0xdc/0xec
 deferred_probe_work_func+0xa8/0xd4
 process_one_work+0x3dc/0x96c
 worker_thread+0x4ec/0x8bc
 kthread+0x230/0x240
 ret_from_fork+0x14/0x38
   (null)

Freed by task 132:
 __kasan_slab_free+0x12c/0x200
 kasan_slab_free+0x14/0x18
 kfree+0x90/0x294
 hwmon_dev_release+0x1c/0x20
 device_release+0x4c/0xe8
 kobject_put+0xac/0x11c
 device_unregister+0x2c/0x30
 __hwmon_device_register+0xa58/0xa7c
 hwmon_device_register_with_info+0xa0/0xa8
 devm_hwmon_device_register_with_info+0x74/0xb4
 lm90_probe+0x414/0x578
 i2c_device_probe+0x35c/0x384
 really_probe+0x290/0x3e4
 driver_probe_device+0x80/0x1c4
 __device_attach_driver+0x104/0x11c
 bus_for_each_drv+0xa4/0xc8
 __device_attach+0xf0/0x15c
 device_initial_probe+0x1c/0x20
 bus_probe_device+0xdc/0xec
 deferred_probe_work_func+0xa8/0xd4
 process_one_work+0x3dc/0x96c
 worker_thread+0x4ec/0x8bc
 kthread+0x230/0x240
 ret_from_fork+0x14/0x38
   (null)

Cc: <stable@vger.kernel.org> # v4.15+
Fixes: 47c332de ("hwmon: Deal with errors from the thermal subsystem")
Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      74e35127
  33. Oct 12, 2018
    • Nicolin Chen's avatar
      hwmon: (core) Add trace events to _attr_show/store functions · 61b8ab2c
      Nicolin Chen authored 
      
Trace events are useful for people who collect data from the
Ftrace outputs. There're people who analyse the relationship
of cpufreq, thermal and hwmon (power/voltage/current) using
the convenient and timestamped Ftrace outputs, while unlike
cpufreq and thermal subsystems the hwmon does not have trace
events supported yet.

So this patch adds initial trace events for the hwmon core.
To call hwmon_attr_base() for aligned attr index numbers, it
also moves the function upward.

Ftrace outputs:
 ...: hwmon_attr_show_string: index=2, attr_name=in2_label, val=VDD_5V
 ...: hwmon_attr_show: index=2, attr_name=in2_input, val=5112
 ...: hwmon_attr_show: index=2, attr_name=curr2_input, val=440

Note that the _attr_show and _attr_store functions are tied
to the _with_info API. So a hwmon driver requiring the trace
events feature should use _with_info API to register a hwmon
device.

Signed-off-by: default avatarNicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      61b8ab2c
  35. Oct 11, 2018
  37. Jul 18, 2018
  39. May 21, 2018
  41. Jan 02, 2018
    • Guenter Roeck's avatar
      hwmon: Fix parameter documentation · 3870945a
      Guenter Roeck authored 
      
sparse reports:

drivers/hwmon/hwmon.c:681: warning:
	No description found for parameter 'chip'
drivers/hwmon/hwmon.c:681: warning:
	Excess function parameter 'info' description in
	'hwmon_device_register_with_info'
drivers/hwmon/hwmon.c:789: warning:
	No description found for parameter 'chip'
drivers/hwmon/hwmon.c:789: warning:
	No description found for parameter 'groups'
drivers/hwmon/hwmon.c:789: warning:
	Excess function parameter 'info' description in
	'devm_hwmon_device_register_with_info'

Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      3870945a
  43. Dec 26, 2017
    • Linus Walleij's avatar
      hwmon: Deal with errors from the thermal subsystem · 47c332de
      Linus Walleij authored 
      
If the thermal subsystem returne -EPROBE_DEFER or any other error
when hwmon calls devm_thermal_zone_of_sensor_register(), this is
silently ignored.

I ran into this with an incorrectly defined thermal zone, making
it non-existing and thus this call failed with -EPROBE_DEFER
assuming it would appear later. The sensor was still added
which is incorrect: sensors must strictly be added after the
thermal zones, so deferred probe must be respected.

Fixes: d560168b ("hwmon: (core) New hwmon registration API")
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      47c332de
  45. Aug 13, 2017
  47. Apr 02, 2017
  49. Jan 31, 2017
  51. Jan 25, 2017
  53. Jan 02, 2017
  55. Dec 10, 2016
  57. Oct 24, 2016
  59. Sep 09, 2016