Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 8月, 2020 6 次提交
  3. 24 7月, 2020 1 次提交
    • V
      regulator: fix memory leak on error path of regulator_register() · 9177514c
      由 Vladimir Zapolskiy 提交于 
      The change corrects registration and deregistration on error path
of a regulator, the problem was manifested by a reported memory
leak on deferred probe:

    as3722-regulator as3722-regulator: regulator 13 register failed -517

    # cat /sys/kernel/debug/kmemleak
    unreferenced object 0xecc43740 (size 64):
      comm "swapper/0", pid 1, jiffies 4294937640 (age 712.880s)
      hex dump (first 32 bytes):
        72 65 67 75 6c 61 74 6f 72 2e 32 34 00 5a 5a 5a  regulator.24.ZZZ
        5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
      backtrace:
        [<0c4c3d1c>] __kmalloc_track_caller+0x15c/0x2c0
        [<40c0ad48>] kvasprintf+0x64/0xd4
        [<109abd29>] kvasprintf_const+0x70/0x84
        [<c4215946>] kobject_set_name_vargs+0x34/0xa8
        [<62282ea2>] dev_set_name+0x40/0x64
        [<a39b6757>] regulator_register+0x3a4/0x1344
        [<16a9543f>] devm_regulator_register+0x4c/0x84
        [<51a4c6a1>] as3722_regulator_probe+0x294/0x754
        ...

The memory leak problem was introduced as a side ef another fix in
regulator_register() error path, I believe that the proper fix is
to decouple device_register() function into its two compounds and
initialize a struct device before assigning any values to its fields
and then using it before actual registration of a device happens.

This lets to call put_device() safely after initialization, and, since
now a release callback is called, kfree(rdev->constraints) shall be
removed to exclude a double free condition.

Fixes: a3cde953 ("regulator: core: fix regulator_register() error paths to properly release rdev")
Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
Cc: Wen Yang <wenyang@linux.alibaba.com>
Link: https://lore.kernel.org/r/20200724005013.23278-1-vz@mleia.comSigned-off-by: NMark Brown <broonie@kernel.org>
      9177514c
  5. 20 7月, 2020 1 次提交
  7. 15 7月, 2020 1 次提交
  9. 30 5月, 2020 1 次提交
  11. 29 5月, 2020 1 次提交
  13. 30 4月, 2020 1 次提交
  15. 14 4月, 2020 1 次提交
  17. 14 3月, 2020 1 次提交
  19. 05 3月, 2020 1 次提交
    • J
      regulator: Use driver_deferred_probe_timeout for regulator_init_complete_work · dca0b449
      由 John Stultz 提交于 
      The regulator_init_complete_work logic defers the cleanup for an
arbitrary 30 seconds of time to allow modules loaded by userland
to start.

This arbitrary timeout is similar to the
driver_deferred_probe_timeout value, and its been suggested we
align these so users have a method to extend the timeouts as
needed.

So this patch changes the logic to use the
driver_deferred_probe_timeout value for the delay value if it
is set (using a delay of 0 if it is not).

Cc: linux-pm@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Todd Kjos <tkjos@google.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Rob Herring <robh@kernel.org>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200225050828.56458-7-john.stultz@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dca0b449
  21. 21 1月, 2020 1 次提交
  23. 17 1月, 2020 1 次提交
  25. 10 12月, 2019 1 次提交
    • C
      regulator: core: avoid unneeded .list_voltage calls · 6d30fc51
      由 Cristian Marussi 提交于 
      Inside machine_constraints_voltage() a loop is in charge of verifying that
each of the defined voltages are within the configured constraints and
that those constraints are in fact compatible with the available voltages'
list.

When the registered regulator happens to be defined with a wide range of
possible voltages the above O(n) loop can be costly.
Moreover since this behaviour is triggered during the registration process,
it means also that it can be easily triggered at probe time, slowing down
considerably some module loading.

On the other side if such wide range of voltage values happens to be also
continuous and without discontinuity of any kind, the above potentially
cumbersome operation is also useless.

For these reasons, avoid such .list_voltage poll loop when regulator is
described as 'continuous_voltage_range' as is, indeed, similarly already
done inside regulator_is_supported_voltage().
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20191209125239.46054-1-cristian.marussi@arm.comSigned-off-by: NMark Brown <broonie@kernel.org>
      6d30fc51
  27. 03 12月, 2019 1 次提交
  29. 27 11月, 2019 1 次提交
  31. 15 11月, 2019 2 次提交
  33. 28 10月, 2019 2 次提交
  35. 17 9月, 2019 1 次提交
  37. 11 9月, 2019 1 次提交
  39. 04 9月, 2019 1 次提交
    • M
      regulator: Defer init completion for a while after late_initcall · 55576cf1
      由 Mark Brown 提交于 
      The kernel has no way of knowing when we have finished instantiating
drivers, between deferred probe and systems that build key drivers as
modules we might be doing this long after userspace has booted. This has
always been a bit of an issue with regulator_init_complete since it can
power off hardware that's not had it's driver loaded which can result in
user visible effects, the main case is powering off displays. Practically
speaking it's not been an issue in real systems since most systems that
use the regulator API are embedded and build in key drivers anyway but
with Arm laptops coming on the market it's becoming more of an issue so
let's do something about it.

In the absence of any better idea just defer the powering off for 30s
after late_initcall(), this is obviously a hack but it should mask the
issue for now and it's no more arbitrary than late_initcall() itself.
Ideally we'd have some heuristics to detect if we're on an affected
system and tune or skip the delay appropriately, and there may be some
need for a command line option to be added.

Link: https://lore.kernel.org/r/20190904124250.25844-1-broonie@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>
Tested-by: NLee Jones <lee.jones@linaro.org>
Cc: stable@vger.kernel.org
      55576cf1
  41. 16 8月, 2019 1 次提交
  43. 05 8月, 2019 1 次提交
  45. 05 7月, 2019 1 次提交
  47. 25 6月, 2019 2 次提交
  49. 19 6月, 2019 1 次提交
  51. 15 6月, 2019 1 次提交
  53. 31 5月, 2019 1 次提交
  55. 08 5月, 2019 1 次提交
  57. 03 5月, 2019 1 次提交
  59. 26 4月, 2019 2 次提交
  61. 05 4月, 2019 1 次提交
    • C
      regulator: core: Avoid potential deadlock on regulator_unregister · 06377301
      由 Charles Keepax 提交于 
      Lockdep reports the following issue on my setup:

Possible unsafe locking scenario:

CPU0                    CPU1
----                    ----
lock((work_completion)(&(&rdev->disable_work)->work));
                        lock(regulator_list_mutex);
                        lock((work_completion)(&(&rdev->disable_work)->work));
lock(regulator_list_mutex);

The problem is that regulator_unregister takes the
regulator_list_mutex and then calls flush_work on disable_work. But
regulator_disable_work calls regulator_lock_dependent which will
also take the regulator_list_mutex. Resulting in a deadlock if the
flush_work call actually needs to flush the work.

Fix this issue by moving the flush_work outside of the
regulator_list_mutex. The list mutex is not used to guard the point at
which the delayed work is queued, so its use adds no additional safety.

Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      06377301