lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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