From: Mark Brown <broonie@kernel.org>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
"Liam Girdwood" <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: regulator: deadlock vs memory reclaim
Date: Mon, 10 Aug 2020 20:51:23 +0100 [thread overview]
Message-ID: <20200810195123.GJ6438@sirena.org.uk> (raw)
In-Reply-To: <08f030a2-3a6f-3ab4-1855-3016884db79d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]
On Mon, Aug 10, 2020 at 10:41:54PM +0300, Dmitry Osipenko wrote:
> 10.08.2020 22:25, Michał Mirosław пишет:
> >> The initialization cases that are the trigger are only done for coupled
> >> regulators though AFAICT, otherwise we're not doing allocations with the
> >> lock held and should be able to progress.
> > I caught a few lockdep complaints that suggest otherwise, but I'm still
> > looking into that.
> The problem looks obvious to me. The regulator_init_coupling() is
> protected with the list_mutex, the regulator_lock_dependent() also
> protected with the list_mutex. Hence if offending reclaim happens from
> init_coupling(), then there is a lockup.
We may also have problems if I/O triggers allocations for some reason,
though that's also going to be a limited set of cases. Might be what
lockdep was showing though.
> It should be enough just to keep the regulator_find_coupler() under
> lock, or even completely remove the locking around init_coupling(). I
> think it should be better to keep the find_coupler() protected.
> Michał, does this fix yours problem?
That was the sort of thing I was thinking about here - it should at
least be an improvement if nothing else.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-08-10 19:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-09 22:25 Michał Mirosław
2020-08-10 0:09 ` Dmitry Osipenko
2020-08-10 15:39 ` Mark Brown
2020-08-10 16:09 ` Michał Mirosław
2020-08-10 17:31 ` Mark Brown
2020-08-10 19:25 ` Michał Mirosław
2020-08-10 19:41 ` Dmitry Osipenko
2020-08-10 19:51 ` Mark Brown [this message]
[not found] <cover.1597089543.git.mirq-linux@rere.qmqm.pl>
2020-08-10 20:15 ` Dmitry Osipenko
2020-08-10 20:18 ` Michał Mirosław
2020-08-10 20:21 ` Dmitry Osipenko
2020-08-10 20:56 ` Dmitry Osipenko
2020-08-10 21:23 ` Dmitry Osipenko
2020-08-11 0:07 ` Michał Mirosław
2020-08-11 15:44 ` 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=20200810195123.GJ6438@sirena.org.uk \
--to=broonie@kernel.org \
--cc=digetx@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mirq-linux@rere.qmqm.pl \
/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®