[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4h2EsZO2g+YVyVVJFx_Cv3wiZH+xNj=koAux1+_uuF1UA@mail.gmail.com>
Date: Sun, 17 Dec 2017 09:22:52 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Christoph Hellwig <hch@....de>
Cc: Jérôme Glisse <jglisse@...hat.com>,
Logan Gunthorpe <logang@...tatee.com>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
X86 ML <x86@...nel.org>, Linux MM <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 04/17] mm: pass the vmem_altmap to arch_add_memory and __add_pages
On Fri, Dec 15, 2017 at 5:48 PM, Dan Williams <dan.j.williams@...el.com> wrote:
> On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig <hch@....de> wrote:
>> We can just pass this on instead of having to do a radix tree lookup
>> without proper locking 2 levels into the callchain.
>>
>> Signed-off-by: Christoph Hellwig <hch@....de>
>
> Yeah, the lookup of vmem_altmap is too magical and surprising this is better.
>
> Reviewed-by: Dan Williams <dan.j.williams@...el.com>
I'll also note that the locking is not necessary in the memory map
init path because we can't possibly be racing mutations of the radix
as everyone who might touch the radix is serialized by the
mem_hotplug_begin() lock. It's only accesses outside of the
arch_{add,remove}_memory() that need the rcu lock. However, that is
another subtle/magic assumption of this code and its better to pass
the altmap down through the call chain. I just don't want people
thinking that -stable needs to pick any of this up, because afaics the
locking is fine as is, and we can drop that mention from the
changelog.
Powered by blists - more mailing lists