[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200117144209.GA19428@dhcp22.suse.cz>
Date: Fri, 17 Jan 2020 15:42:09 +0100
From: Michal Hocko <mhocko@...nel.org>
To: Qian Cai <cai@....pw>
Cc: David Hildenbrand <david@...hat.com>, akpm@...ux-foundation.org,
sergey.senozhatsky.work@...il.com, pmladek@...e.com,
rostedt@...dmis.org, peterz@...radead.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next v4] mm/hotplug: silence a lockdep splat with
printk()
On Fri 17-01-20 07:40:15, Qian Cai wrote:
>
>
> > On Jan 17, 2020, at 3:51 AM, David Hildenbrand <david@...hat.com> wrote:
> >
> > -> you are accessing the pageblock without the zone lock. It could
> > change to "isolate" again in the meantime if I am not wrong!
>
> Since we are just dumping the state for debugging, it should be fine
> to accept a bit inaccuracy here due to racing. I could put a bit
> comments over there.
Sorry, I could have been more specific. The race I was talking about is
not about accuracy. The current code is racy in that sense already
because you are looking at a struct page you do not own so its state can
change at any time. Please note that the zone->lock doesn't really
prevent from the state transition because that applies only to free
pages and those are obviously OK. So this is not really different.
The race I've had in mind is a when a parallel hotplug would simply
hotremove the section along with the memmap so the struct page was a
complete garbage.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists