[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a90aa8fc-0612-3107-93c6-9e4b706785db@oracle.com>
Date: Tue, 6 Mar 2018 16:48:31 -0500
From: Pavel Tatashin <pasha.tatashin@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Steven Sistare <steven.sistare@...cle.com>,
Daniel Jordan <daniel.m.jordan@...cle.com>,
Masayoshi Mizuma <m.mizuma@...fujitsu.com>,
Michal Hocko <mhocko@...e.com>,
Catalin Marinas <catalin.marinas@....com>,
AKASHI Takahiro <takahiro.akashi@...aro.org>,
Gioh Kim <gi-oh.kim@...fitbricks.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Yaowei Bai <baiyaowei@...s.chinamobile.com>,
Wei Yang <richard.weiyang@...il.com>,
Paul Burton <paul.burton@...s.com>,
Miles Chen <miles.chen@...iatek.com>,
Vlastimil Babka <vbabka@...e.cz>, Mel Gorman <mgorman@...e.de>,
Johannes Weiner <hannes@...xchg.org>,
LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: [PATCH] mm: might_sleep warning
> That's why page_alloc_init_late() needs spin_lock_irq(). If a CPU is
> holding deferred_zone_grow_lock with enabled interrupts and an
> interrupt comes in on that CPU and the CPU runs deferred_grow_zone() in
> its interrupt handler, we deadlock.
>
> lockdep knows about this bug and should have reported it.
>
I see what you are saying. Yes you are correct, we need spin_lock_irq()
in page_alloc_init_late(). I will update the patch. I am not sure why
lockdep has not reported it. May be it is initialized after this code is
executed?
Thank you,
Pavel
Powered by blists - more mailing lists