mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Mark Brown" <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: regulator: deadlock vs memory reclaim
Date: Mon, 10 Aug 2020 23:56:13 +0300	[thread overview]
Message-ID: <81e490af-d1da-873a-51b4-130ca82fd1f6@gmail.com> (raw)
In-Reply-To: <d9c3f307-e124-ea5e-c036-71138f9232f4@gmail.com>

10.08.2020 23:21, Dmitry Osipenko пишет:
> 10.08.2020 23:18, Michał Mirosław пишет:
>> On Mon, Aug 10, 2020 at 11:15:28PM +0300, Dmitry Osipenko wrote:
>>> 10.08.2020 23:09, Michał Mirosław пишет:
>>>> At first I also thought so, but there's more. Below is a lockdep
>>>> complaint with your patch applied. I did a similar patch and then two more
>>>> (following) and that is still not enough (sysfs/debugfs do allocations,
>>>> too).
>>> Then it should be good to move the locking for init_coupling() like I
>>> suggested and use GFP_NOWAIT for the two other cases. It all could be a
>>> single small patch. Could you please check whether GFP_NOWAIT helps?
>>
>> This would be equivalent to my patches. Problem with sysfs and debugfs
>> remains as they don't have the option of GFP_NOWAIT. This needs to be
>> moved outside of the locks.
> 
> Ah okay, you meant the debugfs core. I see now, thanks.
> 

This indeed needs a capital solution.

It's not obvious how to fix it.. we can probably remove taking the
list_mutex from lock_dependent(), but this still won't help the case of
memory reclaiming because reclaim may cause touching the already locked
regulator. IIUC, the case of memory reclaiming under regulator lock was
always dangerous and happened to work by chance before, correct?

  reply	other threads:[~2020-08-10 20:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1597089543.git.mirq-linux@rere.qmqm.pl>
2020-08-10 20:09 ` [RFC PATCH 2/3] regulator: push enable_gpio allocation out from under regulator_list_mutex Michał Mirosław
2020-08-10 20:09 ` [RFC PATCH 1/3] regulator: allocate memory outside of regulator_list mutex Michał Mirosław
2020-08-10 20:09 ` [RFC PATCH 3/3] regulator: push supply_name allocation outside of lock Michał Mirosław
2020-08-10 20:15 ` regulator: deadlock vs memory reclaim Dmitry Osipenko
2020-08-10 20:18   ` Michał Mirosław
2020-08-10 20:21     ` Dmitry Osipenko
2020-08-10 20:56       ` Dmitry Osipenko [this message]
2020-08-10 21:23         ` Dmitry Osipenko
2020-08-11  0:07         ` Michał Mirosław
2020-08-11 15:44           ` Dmitry Osipenko
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

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=81e490af-d1da-873a-51b4-130ca82fd1f6@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 \
    /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

Powered by JetHome