mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 --]

  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®