All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"mpe@ellerman.id.au" <mpe@ellerman.id.au>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH 3/3] powerpc/mm: Use VMALLOC_START to validate addr
Date: Mon, 27 Jun 2022 10:19:15 +0530	[thread overview]
Message-ID: <874k06zp6c.fsf@linux.ibm.com> (raw)
In-Reply-To: <0a024d97-93d3-18c7-a14c-818b698a8516@csgroup.eu>

Christophe Leroy <christophe.leroy@csgroup.eu> writes:

> Le 23/06/2022 à 14:29, Aneesh Kumar K.V a écrit :
>> Instead of high_memory use VMALLOC_START to validate that the address is
>> not in the vmalloc range.
>
> What's the reason for using VMALLOC_START instead ?
> The gap between high_memory and VMALLOC_START should not be seen as 
> valid memory either, should it ?

Yes and that invalid range should be captured by the pfn_valid check.
Commit ffa0b64e3be5 intended to skip the vmalloc range.
Unfortunately, that resulted in kernel crash due to architecture not
updating high_memory after a memory hotplug. That should be fixed by
patch 1 in this series. patch 3 was added merely as a cleanup to
switch from high_memory to a more familiar VMALLOC_START variable.

>
> If the problem is book3s/64, commit ffa0b64e3be5 ("powerpc: Fix 
> virt_addr_valid() for 64-bit Book3E & 32-bit") says that those 
> additional tests are superfluous for boo3s/64. Maybe it's time to drop 
> unnecessary tests for book3s/64 ?

They are not specific book3s/64. IIUC virt_addr_valid will return false
for an addr after memory hotplug on other platforms too. Patch 1
describe those details.

>
>> 
>> Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
>> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>>   arch/powerpc/include/asm/page.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
>> index e5f75c70eda8..256cad69e42e 100644
>> --- a/arch/powerpc/include/asm/page.h
>> +++ b/arch/powerpc/include/asm/page.h
>> @@ -134,7 +134,7 @@ static inline bool pfn_valid(unsigned long pfn)
>>   
>>   #define virt_addr_valid(vaddr)	({					\
>>   	unsigned long _addr = (unsigned long)vaddr;			\
>> -	_addr >= PAGE_OFFSET && _addr < (unsigned long)high_memory &&	\
>> +	_addr >= PAGE_OFFSET && _addr < (unsigned long)VMALLOC_START &&	\
>>   	pfn_valid(virt_to_pfn(_addr));					\
>>   })
>>   

WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"mpe@ellerman.id.au" <mpe@ellerman.id.au>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	Michal Hocko <mhocko@suse.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>
Subject: Re: [PATCH 3/3] powerpc/mm: Use VMALLOC_START to validate addr
Date: Mon, 27 Jun 2022 10:19:15 +0530	[thread overview]
Message-ID: <874k06zp6c.fsf@linux.ibm.com> (raw)
In-Reply-To: <0a024d97-93d3-18c7-a14c-818b698a8516@csgroup.eu>

Christophe Leroy <christophe.leroy@csgroup.eu> writes:

> Le 23/06/2022 à 14:29, Aneesh Kumar K.V a écrit :
>> Instead of high_memory use VMALLOC_START to validate that the address is
>> not in the vmalloc range.
>
> What's the reason for using VMALLOC_START instead ?
> The gap between high_memory and VMALLOC_START should not be seen as 
> valid memory either, should it ?

Yes and that invalid range should be captured by the pfn_valid check.
Commit ffa0b64e3be5 intended to skip the vmalloc range.
Unfortunately, that resulted in kernel crash due to architecture not
updating high_memory after a memory hotplug. That should be fixed by
patch 1 in this series. patch 3 was added merely as a cleanup to
switch from high_memory to a more familiar VMALLOC_START variable.

>
> If the problem is book3s/64, commit ffa0b64e3be5 ("powerpc: Fix 
> virt_addr_valid() for 64-bit Book3E & 32-bit") says that those 
> additional tests are superfluous for boo3s/64. Maybe it's time to drop 
> unnecessary tests for book3s/64 ?

They are not specific book3s/64. IIUC virt_addr_valid will return false
for an addr after memory hotplug on other platforms too. Patch 1
describe those details.

>
>> 
>> Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
>> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>>   arch/powerpc/include/asm/page.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
>> index e5f75c70eda8..256cad69e42e 100644
>> --- a/arch/powerpc/include/asm/page.h
>> +++ b/arch/powerpc/include/asm/page.h
>> @@ -134,7 +134,7 @@ static inline bool pfn_valid(unsigned long pfn)
>>   
>>   #define virt_addr_valid(vaddr)	({					\
>>   	unsigned long _addr = (unsigned long)vaddr;			\
>> -	_addr >= PAGE_OFFSET && _addr < (unsigned long)high_memory &&	\
>> +	_addr >= PAGE_OFFSET && _addr < (unsigned long)VMALLOC_START &&	\
>>   	pfn_valid(virt_to_pfn(_addr));					\
>>   })
>>   


  reply	other threads:[~2022-06-27  4:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-23 12:29 [PATCH 1/3] powerpc/memhotplug: Add add_pages override for PPC Aneesh Kumar K.V
2022-06-23 12:29 ` Aneesh Kumar K.V
2022-06-23 12:29 ` [PATCH 2/3] powerpc/mm: Update max/min_low_pfn in the same function Aneesh Kumar K.V
2022-06-23 12:29 ` [PATCH 3/3] powerpc/mm: Use VMALLOC_START to validate addr Aneesh Kumar K.V
2022-06-23 12:29   ` Aneesh Kumar K.V
2022-06-24  2:45   ` Michael Ellerman
2022-06-24  2:45     ` Michael Ellerman
2022-06-27  4:44     ` Aneesh Kumar K.V
2022-06-27  4:44       ` Aneesh Kumar K.V
2022-06-24 11:51   ` Christophe Leroy
2022-06-24 11:51     ` Christophe Leroy
2022-06-27  4:49     ` Aneesh Kumar K.V [this message]
2022-06-27  4:49       ` Aneesh Kumar K.V
2022-06-27  5:42   ` Christophe Leroy
2022-06-27  5:42     ` Christophe Leroy
2022-06-27  6:49     ` Aneesh Kumar K.V
2022-06-27  6:49       ` Aneesh Kumar K.V

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874k06zp6c.fsf@linux.ibm.com \
    --to=aneesh.kumar@linux.ibm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mhocko@suse.com \
    --cc=mpe@ellerman.id.au \
    --cc=wangkefeng.wang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.