All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Qian Cai <cai@lca.pw>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Oscar Salvador <osalvador@suse.de>,
	Mel Gorman <mgorman@techsingularity.net>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Pavel Tatashin <pavel.tatashin@microsoft.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/page_alloc: Add a reason for reserved pages in has_unmovable_pages()
Date: Fri, 4 Oct 2019 16:41:50 +0200	[thread overview]
Message-ID: <20191004144150.GO9578@dhcp22.suse.cz> (raw)
In-Reply-To: <1570197360.5576.275.camel@lca.pw>

On Fri 04-10-19 09:56:00, Qian Cai wrote:
> On Fri, 2019-10-04 at 15:38 +0200, Michal Hocko wrote:
> > On Fri 04-10-19 09:30:39, Qian Cai wrote:
> > > On Fri, 2019-10-04 at 15:07 +0200, Michal Hocko wrote:
> > > > On Fri 04-10-19 08:56:16, Qian Cai wrote:
> > > > [...]
> > > > > It might be a good time to rethink if it is really a good idea to dump_page()
> > > > > at all inside has_unmovable_pages(). As it is right now, it is a a potential
> > > > > deadlock between console vs memory offline. More details are in this thread,
> > > > > 
> > > > > https://lore.kernel.org/lkml/1568817579.5576.172.camel@lca.pw/
> > > > 
> > > > Huh. That would imply we cannot do any printk from that path, no?
> > > 
> > > Yes, or use something like printk_deferred()
> > 
> > This is just insane. The hotplug code is in no way special wrt printk.
> > It is never called from the printk code AFAIK and thus there is no real
> > reason why this particular code should be any special. Not to mention
> > it calls printk indirectly from a code that is shared with other code
> > paths.
> 
> Basically, printk() while holding the zone_lock will be problematic as console
> is doing the opposite as it always needs to allocate some memory. Then, it will
> always find some way to form this chain,
> 
> console_lock -> * -> zone_lock.

So this is not as much a hotplug specific problem but zone->lock ->
printk -> alloc chain that is a problem, right? Who is doing an
allocation from this atomic context? I do not see any atomic allocation
in kernel/printk/printk.c.
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2019-10-04 14:41 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-03  8:10 [PATCH] mm/page_alloc: Add a reason for reserved pages in has_unmovable_pages() Anshuman Khandual
2019-10-03  9:05 ` Qian Cai
2019-10-03  9:32   ` Anshuman Khandual
2019-10-03  9:53     ` Anshuman Khandual
2019-10-03 11:19     ` Qian Cai
2019-10-03 11:32       ` Anshuman Khandual
2019-10-03 11:50         ` Qian Cai
2019-10-03 12:02           ` Anshuman Khandual
2019-10-03 12:14             ` Qian Cai
2019-10-04  8:25               ` David Hildenbrand
2020-01-14  8:19                 ` Anshuman Khandual
2020-01-14  8:30                   ` David Hildenbrand
2020-01-14  9:10                   ` Michal Hocko
2020-01-14 10:23                     ` Vlastimil Babka
2020-01-14 11:03                       ` Anshuman Khandual
2020-01-14 11:32                       ` Michal Hocko
2020-01-14 12:04                         ` [PATCH] mm, debug: always print flags in dump_page() Vlastimil Babka
2020-01-14 13:35                           ` Michal Hocko
2020-01-14 18:22                         ` [PATCH] mm/page_alloc: Add a reason for reserved pages in has_unmovable_pages() Ralph Campbell
2019-10-04 10:58 ` Michal Hocko
2019-10-04 11:44   ` Anshuman Khandual
2019-10-04 12:56     ` Qian Cai
2019-10-04 12:56       ` Qian Cai
2019-10-04 13:07       ` Michal Hocko
2019-10-04 13:30         ` Qian Cai
2019-10-04 13:30           ` Qian Cai
2019-10-04 13:38           ` Michal Hocko
2019-10-04 13:56             ` Qian Cai
2019-10-04 13:56               ` Qian Cai
2019-10-04 14:41               ` Michal Hocko [this message]
2019-10-05 21:22                 ` Andrew Morton
2019-10-05 22:38                   ` Qian Cai

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=20191004144150.GO9578@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=cai@lca.pw \
    --cc=dan.j.williams@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=osalvador@suse.de \
    --cc=pavel.tatashin@microsoft.com \
    --cc=rppt@linux.ibm.com \
    --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 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.