From: Dmitry Osipenko <digetx@gmail.com>
To: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
linux-kernel@vger.kernel.org, Vladimir Zapolskiy <vz@mleia.com>
Subject: Re: [PATCH 1/7] regulator: push allocation in regulator_init_coupling() outside of lock
Date: Wed, 12 Aug 2020 00:02:48 +0300 [thread overview]
Message-ID: <813bb196-769b-cffa-d5a0-7a6e6d9aa824@gmail.com> (raw)
In-Reply-To: <20200811172015.GA21273@qmqm.qmqm.pl>
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@gmail.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.
next prev parent reply other threads:[~2020-08-11 21:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 1:07 [PATCH 0/7] regulator: fix deadlock vs memory reclaim Michał Mirosław
2020-08-11 1:07 ` [PATCH 1/7] regulator: push allocation in regulator_init_coupling() outside of lock Michał Mirosław
2020-08-11 15:59 ` Dmitry Osipenko
2020-08-11 16:27 ` Dmitry Osipenko
2020-08-11 17:20 ` Michał Mirosław
2020-08-11 21:02 ` Dmitry Osipenko [this message]
2020-08-11 1:07 ` [PATCH 3/7] regulator: push allocations in create_regulator() " Michał Mirosław
2020-08-11 1:07 ` [PATCH 2/7] regulator: push allocation in regulator_ena_gpio_request() out " Michał Mirosław
2020-08-11 1:07 ` [PATCH 4/7] regulator: push allocation in set_consumer_device_supply() " Michał Mirosław
2020-08-11 5:23 ` kernel test robot
2020-08-11 17:28 ` Michał Mirosław
2020-08-11 1:07 ` [PATCH 6/7] regulator: cleanup regulator_ena_gpio_free() Michał Mirosław
2020-08-11 1:07 ` [PATCH 5/7] regulator: plug of_node leak in regulator_register()'s error path Michał Mirosław
2020-08-11 6:15 ` Vladimir Zapolskiy
2020-08-11 1:07 ` [PATCH 7/7] regulator: remove superfluous lock in regulator_resolve_coupling() Michał Mirosław
2020-08-11 15:56 ` Dmitry Osipenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=813bb196-769b-cffa-d5a0-7a6e6d9aa824@gmail.com \
--to=digetx@gmail.com \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mirq-linux@rere.qmqm.pl \
--cc=vz@mleia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®