linux-kernel - Re: [PATCH 1/7] regulator: push allocation in regulator_init

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: <813bb196-769b-cffa-d5a0-7a6e6d9aa824@gmail.com>
Date:   Wed, 12 Aug 2020 00:02:48 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Michał Mirosław <mirq-linux@...e.qmqm.pl>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>, linux-kernel@...r.kernel.org,
        Vladimir Zapolskiy <vz@...ia.com>
Subject: Re: [PATCH 1/7] regulator: push allocation in
 regulator_init_coupling() outside of lock

11.08.2020 20:20, Michał Mirosław пишет:
> On Tue, Aug 11, 2020 at 07:27:43PM +0300, Dmitry Osipenko wrote:
>> 11.08.2020 18:59, Dmitry Osipenko пишет:
>>> 11.08.2020 04:07, Michał Mirosław пишет:
>>>> Allocating memory with regulator_list_mutex held makes lockdep unhappy
>>>> when memory pressure makes the system do fs_reclaim on eg. eMMC using
>>>> a regulator. Push the lock inside regulator_init_coupling() after the
>>>> allocation.
>>> ...
>>>
>>> Reviewed-by: Dmitry Osipenko <digetx@...il.com>
>> On the other hand, couldn't it be better to just remove taking the
>> list_mutex from the regulator_lock_dependent()?
>>
>> I think the list_mutex is only needed to protect from supply/couple
>> regulator being removed during of the locking process, but maybe this is
>> not something we should worry about?
> 
> This is what I would like to see in the end, but it requires more
> thought, at least around interaction with regulator_resolve_coupling()
> and the regulator removal.

I meant that it's very unlikely to have regulator gone while it's
in-use. Hence it could be okay to ignore this rare case, and thus,
simplify the fix significantly by removing the offending lock.

Still this won't solve the root of the problem because potentially
reclaim could happen while storage regulator (or its supply) is locked,
although it should be a very unlikely condition in practice.