From: Pavel Tatashin <pasha.tatashin@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Steven Sistare <steven.sistare@oracle.com>,
Daniel Jordan <daniel.m.jordan@oracle.com>,
Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>,
Michal Hocko <mhocko@suse.com>,
Catalin Marinas <catalin.marinas@arm.com>,
AKASHI Takahiro <takahiro.akashi@linaro.org>,
Gioh Kim <gi-oh.kim@profitbricks.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Yaowei Bai <baiyaowei@cmss.chinamobile.com>,
Wei Yang <richard.weiyang@gmail.com>,
Paul Burton <paul.burton@mips.com>,
Miles Chen <miles.chen@mediatek.com>,
Vlastimil Babka <vbabka@suse.cz>, Mel Gorman <mgorman@suse.de>,
Johannes Weiner <hannes@cmpxchg.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: might_sleep warning
Date: Tue, 6 Mar 2018 15:48:26 -0500 [thread overview]
Message-ID: <CAGM2rea1raxsXDkqZgmmdBiuywp1M3y1p++=J893VJDgGDWLnQ@mail.gmail.com> (raw)
In-Reply-To: <20180306123655.957e5b6b20b200505544ea7a@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]
[CCed everyone]
Hi Andrew,
I afraid we cannot change this spinlock to mutex
because deferred_grow_zone() might be called from an interrupt context if
interrupt thread needs to allocate memory.
Thank you,
Pavel
On Tue, Mar 6, 2018 at 3:36 PM, Andrew Morton <akpm@linux-foundation.org>
wrote:
> On Tue, 6 Mar 2018 14:20:22 -0500 Pavel Tatashin <
> pasha.tatashin@oracle.com> wrote:
>
> > Robot reported this issue:
> > https://lkml.org/lkml/2018/2/27/851
> >
> > That is introduced by:
> > mm: initialize pages on demand during boot
> >
> > The problem is caused by changing static branch value within spin lock.
> > Spin lock disables preemption, and changing static branch value takes
> > mutex lock in its path, and thus may sleep.
> >
> > The fix is to add another boolean variable to avoid the need to change
> > static branch within spinlock.
> >
> > ...
> >
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1579,6 +1579,7 @@ static int __init deferred_init_memmap(void *data)
> > * page_alloc_init_late() soon after smp_init() is complete.
> > */
> > static __initdata DEFINE_SPINLOCK(deferred_zone_grow_lock);
> > +static bool deferred_zone_grow __initdata = true;
> > static DEFINE_STATIC_KEY_TRUE(deferred_pages);
> >
> > /*
> > @@ -1616,7 +1617,7 @@ deferred_grow_zone(struct zone *zone, unsigned int
> order)
> > * Bail if we raced with another thread that disabled on demand
> > * initialization.
> > */
> > - if (!static_branch_unlikely(&deferred_pages)) {
> > + if (!static_branch_unlikely(&deferred_pages) ||
> !deferred_zone_grow) {
> > spin_unlock_irqrestore(&deferred_zone_grow_lock, flags);
> > return false;
> > }
> > @@ -1683,10 +1684,15 @@ void __init page_alloc_init_late(void)
> > /*
> > * We are about to initialize the rest of deferred pages,
> permanently
> > * disable on-demand struct page initialization.
> > + *
> > + * Note: it is prohibited to modify static branches in
> non-preemptible
> > + * context. Since, spin_lock() disables preemption, we must use an
> > + * extra boolean deferred_zone_grow.
> > */
> > spin_lock(&deferred_zone_grow_lock);
> > - static_branch_disable(&deferred_pages);
> > + deferred_zone_grow = false;
> > spin_unlock(&deferred_zone_grow_lock);
> > + static_branch_disable(&deferred_pages);
> >
> > /* There will be num_node_state(N_MEMORY) threads */
> > atomic_set(&pgdat_init_n_undone, num_node_state(N_MEMORY));
>
> Kinda ugly, but I can see the logic behind the decisions.
>
> Can we instead turn deferred_zone_grow_lock into a mutex?
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
[-- Attachment #2: Type: text/html, Size: 7336 bytes --]
next prev parent reply other threads:[~2018-03-06 20:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-06 19:20 Pavel Tatashin
2018-03-06 20:36 ` Andrew Morton
2018-03-06 20:48 ` Pavel Tatashin [this message]
2018-03-06 20:56 ` Andrew Morton
2018-03-06 21:04 ` Pavel Tatashin
2018-03-06 21:21 ` Andrew Morton
2018-03-06 21:48 ` Pavel Tatashin
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='CAGM2rea1raxsXDkqZgmmdBiuywp1M3y1p++=J893VJDgGDWLnQ@mail.gmail.com' \
--to=pasha.tatashin@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baiyaowei@cmss.chinamobile.com \
--cc=catalin.marinas@arm.com \
--cc=daniel.m.jordan@oracle.com \
--cc=gi-oh.kim@profitbricks.com \
--cc=hannes@cmpxchg.org \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.mizuma@jp.fujitsu.com \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=miles.chen@mediatek.com \
--cc=paul.burton@mips.com \
--cc=richard.weiyang@gmail.com \
--cc=steven.sistare@oracle.com \
--cc=takahiro.akashi@linaro.org \
--cc=vbabka@suse.cz \
/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