[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <556a8a62-7bb2-d16b-67ea-57c87c1a6aa7@redhat.com>
Date: Tue, 12 Jan 2021 11:09:34 +0100
From: David Hildenbrand <david@...hat.com>
To: Anshuman Khandual <anshuman.khandual@....com>,
Oscar Salvador <osalvador@...e.de>
Cc: linux-mm@...ck.org, akpm@...ux-foundation.org, hca@...ux.ibm.com,
catalin.marinas@....com, linux-arm-kernel@...ts.infradead.org,
linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
Vasily Gorbik <gor@...ux.ibm.com>,
Will Deacon <will@...nel.org>,
Ard Biesheuvel <ardb@...nel.org>,
Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH V2 1/3] mm/hotplug: Prevalidate the address range being
added with platform
On 12.01.21 04:51, Anshuman Khandual wrote:
>
>
> On 1/11/21 7:13 PM, Oscar Salvador wrote:
>> On Mon, Jan 11, 2021 at 11:51:47AM +0100, David Hildenbrand wrote:
>>> AFAIKs, all memhp_get_pluggable_range() users pass "1".
>>>
>>> What about the "add_pages()-only" path?
>>
>> I guess you refer to memremap_pages(), right?
>
> Right, via pagemap_range().
>
>> If so, moving the added memhp_range_allowed() check above the if-else might do
>> the trick
>>
> We had that code in the earlier version. But dropped it, as we did
> not want to add any new checks in the generic code. Can add it back
> if that is preferred.
I remember discussing replacing the check in __add_pages() instead. But
I don't really care where the check ends up being. As discussed, at some
point, we should provide versions of add_pages() and arch_add_pages()
that don't immediately end in arch-code.
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists