[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bc46b390-01b8-e818-588d-f973dc2c5140@arm.com>
Date: Fri, 21 Jun 2019 18:23:22 +0530
From: Anshuman Khandual <anshuman.khandual@....com>
To: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, akpm@...ux-foundation.org,
catalin.marinas@....com, will.deacon@....com
Cc: mark.rutland@....com, mhocko@...e.com, ira.weiny@...el.com,
david@...hat.com, cai@....pw, logang@...tatee.com,
james.morse@....com, cpandya@...eaurora.org, arunks@...eaurora.org,
dan.j.williams@...el.com, mgorman@...hsingularity.net,
osalvador@...e.de, ard.biesheuvel@....com, steve.capper@....com
Subject: Re: [PATCH V6 3/3] arm64/mm: Enable memory hot remove
On 06/19/2019 09:47 AM, Anshuman Khandual wrote:
> +#ifdef CONFIG_MEMORY_HOTPLUG
> + /*
> + * FIXME: We should have called remove_pagetable(start, end, true).
> + * vmemmap and vmalloc virtual range might share intermediate kernel
> + * page table entries. Removing vmemmap range page table pages here
> + * can potentially conflict with a cuncurrent vmalloc() allocation.
> + *
> + * This is primarily because valloc() does not take init_mm ptl for
> + * the entire page table walk and it's modification. Instead it just
> + * takes the lock while allocating and installing page table pages
> + * via [p4d|pud|pmd|pte]_aloc(). A cuncurrently vanishing page table
> + * entry via memory hotremove can cause vmalloc() kernel page table
> + * walk pointers to be invalid on the fly which can cause corruption
> + * or worst, a crash.
There are couple of typos above which I will fix along with other reviews.
Powered by blists - more mailing lists