linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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