From: Michal Hocko <mhocko@suse.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
akpm@linux-foundation.org, linux-mm@kvack.org,
kirill.shutemov@linux.intel.com
Subject: Re: [PATCH v2] mm: Warn on lock_page() from reclaim context.
Date: Mon, 19 Mar 2018 11:33:36 +0100 [thread overview]
Message-ID: <20180319103336.GU23100@dhcp22.suse.cz> (raw)
In-Reply-To: <20180319101440.6xe5ixd5nn4zrvl2@node.shutemov.name>
On Mon 19-03-18 13:14:40, Kirill A. Shutemov wrote:
> On Mon, Mar 19, 2018 at 10:04:19AM +0100, Michal Hocko wrote:
> > On Sun 18-03-18 10:22:49, Tetsuo Handa wrote:
> > > >From f43b8ca61b76f9a19c13f6bf42b27fad9554afc0 Mon Sep 17 00:00:00 2001
> > > From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > Date: Sun, 18 Mar 2018 10:18:01 +0900
> > > Subject: [PATCH v2] mm: Warn on lock_page() from reclaim context.
> > >
> > > Kirill A. Shutemov noticed that calling lock_page[_killable]() from
> > > reclaim context might cause deadlock. In order to help finding such
> > > lock_page[_killable]() users (including out of tree users), this patch
> > > emits warning messages when CONFIG_PROVE_LOCKING is enabled.
> >
> > So how do you ensure that this won't cause false possitives? E.g. do we
> > ever allocate while holding the page lock and not having the page on the
> > LRU list?
>
> Hm. Do we even have a reason to lock such pages?
> Probably we do, but I cannot come up with an example.
Page lock is way too obscure to be sure :/
Anyway, maybe we want to be more conservative and only warn about LRU
pages...
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-03-19 10:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-17 14:11 [PATCH] mm: Warn on lock_page() from reclaim context Tetsuo Handa
2018-03-17 15:54 ` Kirill A. Shutemov
2018-03-18 1:22 ` [PATCH v2] " Tetsuo Handa
2018-03-18 8:55 ` Kirill A. Shutemov
2018-03-19 9:04 ` Michal Hocko
2018-03-19 10:14 ` Kirill A. Shutemov
2018-03-19 10:33 ` Michal Hocko [this message]
2018-03-19 10:45 ` Kirill A. Shutemov
2018-03-19 10:55 ` Michal Hocko
2018-03-19 12:04 ` Tetsuo Handa
2018-03-19 22:08 ` Andrew Morton
2018-03-20 8:44 ` Michal Hocko
2018-03-20 17:50 ` Andrew Morton
2018-03-29 7:04 ` [lkp-robot] [mm] 67ffc906f8: WARNING:at_mm/filemap.c:#__warn_lock_page_from_reclaim_context kernel test robot
2018-03-29 7:04 ` kernel test robot
2018-03-29 10:32 ` [lkp-robot] [mm] 67ffc906f8:WARNING:at_mm/filemap.c:#__warn_lock_page_from_reclaim_context Tetsuo Handa
2018-03-29 10:32 ` Tetsuo Handa
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=20180319103336.GU23100@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-mm@kvack.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.