All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "hch@infradead.org" <hch@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vg>
Subject: Re: [PATCH V4 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT
Date: Fri, 24 Jun 2022 11:06:44 +0530	[thread overview]
Message-ID: <e536bd05-dbfd-466b-582e-8a220421a8dc@arm.com> (raw)
In-Reply-To: <10aca763-2313-84bf-9200-6a6037fd748c@csgroup.eu>



On 6/24/22 10:52, Christophe Leroy wrote:
> 
> 
> Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
>> protection_map[] has already been moved inside those platforms which enable
> 
> Usually "already" means before your series.
> 
> Your series is the one that moves protection_map[] so I would have just 
> said "Now that protection_map[] has been moved inside those platforms 
> which enable ...."

Got it, will update the commit message.

> 
>> ARCH_HAS_VM_GET_PAGE_PROT. Hence generic protection_map[] array now can be
>> protected with CONFIG_ARCH_HAS_VM_GET_PAGE_PROT intead of __P000.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>   include/linux/mm.h | 2 +-
>>   mm/mmap.c          | 5 +----
>>   2 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 237828c2bae2..70d900f6df43 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -424,7 +424,7 @@ extern unsigned int kobjsize(const void *objp);
>>    * mapping from the currently active vm_flags protection bits (the
>>    * low four bits) to a page protection mask..
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   extern pgprot_t protection_map[16];
> 
> Is this declaration still needed ? I have the feeling that 
> protection_map[] is only used in mm/mmap.c now.

At this point generic protection_map[] array is still being used via
this declaration on many (!ARCH_HAS_VM_GET_PAGE_PROT) platforms such
as mips, m68k, arm etc.

> 
>>   #endif
>>   
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 55c30aee3999..43db3bd49071 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -101,7 +101,7 @@ static void unmap_region(struct mm_struct *mm,
>>    *								w: (no) no
>>    *								x: (yes) yes
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   pgprot_t protection_map[16] __ro_after_init = {
> 
> Should this be static, as it seems to now be used only in this file ?

This is being used in some platforms as mentioned before.

> And it could also be 'const' instead of __ro_after_init.

Then should be able to be a 'const' wrt  mips, m68k, arm platforms.
But should this even be changed, if this is going to be dropped off
eventually ?

> 
>>   	[VM_NONE]					= __P000,
>>   	[VM_READ]					= __P001,
>> @@ -120,9 +120,6 @@ pgprot_t protection_map[16] __ro_after_init = {
>>   	[VM_SHARED | VM_EXEC | VM_WRITE]		= __S110,
>>   	[VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]	= __S111
>>   };
>> -#endif
>> -
>> -#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   DECLARE_VM_GET_PAGE_PROT
>>   #endif	/* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
>>   

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "hch@infradead.org" <hch@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"linux-snps-arc@lists.infradead.org" 
	<linux-snps-arc@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V4 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT
Date: Fri, 24 Jun 2022 11:06:44 +0530	[thread overview]
Message-ID: <e536bd05-dbfd-466b-582e-8a220421a8dc@arm.com> (raw)
In-Reply-To: <10aca763-2313-84bf-9200-6a6037fd748c@csgroup.eu>



On 6/24/22 10:52, Christophe Leroy wrote:
> 
> 
> Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
>> protection_map[] has already been moved inside those platforms which enable
> 
> Usually "already" means before your series.
> 
> Your series is the one that moves protection_map[] so I would have just 
> said "Now that protection_map[] has been moved inside those platforms 
> which enable ...."

Got it, will update the commit message.

> 
>> ARCH_HAS_VM_GET_PAGE_PROT. Hence generic protection_map[] array now can be
>> protected with CONFIG_ARCH_HAS_VM_GET_PAGE_PROT intead of __P000.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>   include/linux/mm.h | 2 +-
>>   mm/mmap.c          | 5 +----
>>   2 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 237828c2bae2..70d900f6df43 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -424,7 +424,7 @@ extern unsigned int kobjsize(const void *objp);
>>    * mapping from the currently active vm_flags protection bits (the
>>    * low four bits) to a page protection mask..
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   extern pgprot_t protection_map[16];
> 
> Is this declaration still needed ? I have the feeling that 
> protection_map[] is only used in mm/mmap.c now.

At this point generic protection_map[] array is still being used via
this declaration on many (!ARCH_HAS_VM_GET_PAGE_PROT) platforms such
as mips, m68k, arm etc.

> 
>>   #endif
>>   
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 55c30aee3999..43db3bd49071 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -101,7 +101,7 @@ static void unmap_region(struct mm_struct *mm,
>>    *								w: (no) no
>>    *								x: (yes) yes
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   pgprot_t protection_map[16] __ro_after_init = {
> 
> Should this be static, as it seems to now be used only in this file ?

This is being used in some platforms as mentioned before.

> And it could also be 'const' instead of __ro_after_init.

Then should be able to be a 'const' wrt  mips, m68k, arm platforms.
But should this even be changed, if this is going to be dropped off
eventually ?

> 
>>   	[VM_NONE]					= __P000,
>>   	[VM_READ]					= __P001,
>> @@ -120,9 +120,6 @@ pgprot_t protection_map[16] __ro_after_init = {
>>   	[VM_SHARED | VM_EXEC | VM_WRITE]		= __S110,
>>   	[VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]	= __S111
>>   };
>> -#endif
>> -
>> -#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   DECLARE_VM_GET_PAGE_PROT
>>   #endif	/* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
>>   

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "hch@infradead.org" <hch@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V4 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT
Date: Fri, 24 Jun 2022 05:48:44 +0000	[thread overview]
Message-ID: <e536bd05-dbfd-466b-582e-8a220421a8dc@arm.com> (raw)
In-Reply-To: <10aca763-2313-84bf-9200-6a6037fd748c@csgroup.eu>



On 6/24/22 10:52, Christophe Leroy wrote:
> 
> 
> Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
>> protection_map[] has already been moved inside those platforms which enable
> 
> Usually "already" means before your series.
> 
> Your series is the one that moves protection_map[] so I would have just 
> said "Now that protection_map[] has been moved inside those platforms 
> which enable ...."

Got it, will update the commit message.

> 
>> ARCH_HAS_VM_GET_PAGE_PROT. Hence generic protection_map[] array now can be
>> protected with CONFIG_ARCH_HAS_VM_GET_PAGE_PROT intead of __P000.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>   include/linux/mm.h | 2 +-
>>   mm/mmap.c          | 5 +----
>>   2 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 237828c2bae2..70d900f6df43 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -424,7 +424,7 @@ extern unsigned int kobjsize(const void *objp);
>>    * mapping from the currently active vm_flags protection bits (the
>>    * low four bits) to a page protection mask..
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   extern pgprot_t protection_map[16];
> 
> Is this declaration still needed ? I have the feeling that 
> protection_map[] is only used in mm/mmap.c now.

At this point generic protection_map[] array is still being used via
this declaration on many (!ARCH_HAS_VM_GET_PAGE_PROT) platforms such
as mips, m68k, arm etc.

> 
>>   #endif
>>   
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 55c30aee3999..43db3bd49071 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -101,7 +101,7 @@ static void unmap_region(struct mm_struct *mm,
>>    *								w: (no) no
>>    *								x: (yes) yes
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   pgprot_t protection_map[16] __ro_after_init = {
> 
> Should this be static, as it seems to now be used only in this file ?

This is being used in some platforms as mentioned before.

> And it could also be 'const' instead of __ro_after_init.

Then should be able to be a 'const' wrt  mips, m68k, arm platforms.
But should this even be changed, if this is going to be dropped off
eventually ?

> 
>>   	[VM_NONE]					= __P000,
>>   	[VM_READ]					= __P001,
>> @@ -120,9 +120,6 @@ pgprot_t protection_map[16] __ro_after_init = {
>>   	[VM_SHARED | VM_EXEC | VM_WRITE]		= __S110,
>>   	[VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]	= __S111
>>   };
>> -#endif
>> -
>> -#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   DECLARE_VM_GET_PAGE_PROT
>>   #endif	/* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
>>   

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "hch@infradead.org" <hch@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V4 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT
Date: Fri, 24 Jun 2022 11:06:44 +0530	[thread overview]
Message-ID: <e536bd05-dbfd-466b-582e-8a220421a8dc@arm.com> (raw)
In-Reply-To: <10aca763-2313-84bf-9200-6a6037fd748c@csgroup.eu>



On 6/24/22 10:52, Christophe Leroy wrote:
> 
> 
> Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
>> protection_map[] has already been moved inside those platforms which enable
> 
> Usually "already" means before your series.
> 
> Your series is the one that moves protection_map[] so I would have just 
> said "Now that protection_map[] has been moved inside those platforms 
> which enable ...."

Got it, will update the commit message.

> 
>> ARCH_HAS_VM_GET_PAGE_PROT. Hence generic protection_map[] array now can be
>> protected with CONFIG_ARCH_HAS_VM_GET_PAGE_PROT intead of __P000.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>   include/linux/mm.h | 2 +-
>>   mm/mmap.c          | 5 +----
>>   2 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 237828c2bae2..70d900f6df43 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -424,7 +424,7 @@ extern unsigned int kobjsize(const void *objp);
>>    * mapping from the currently active vm_flags protection bits (the
>>    * low four bits) to a page protection mask..
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   extern pgprot_t protection_map[16];
> 
> Is this declaration still needed ? I have the feeling that 
> protection_map[] is only used in mm/mmap.c now.

At this point generic protection_map[] array is still being used via
this declaration on many (!ARCH_HAS_VM_GET_PAGE_PROT) platforms such
as mips, m68k, arm etc.

> 
>>   #endif
>>   
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 55c30aee3999..43db3bd49071 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -101,7 +101,7 @@ static void unmap_region(struct mm_struct *mm,
>>    *								w: (no) no
>>    *								x: (yes) yes
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   pgprot_t protection_map[16] __ro_after_init = {
> 
> Should this be static, as it seems to now be used only in this file ?

This is being used in some platforms as mentioned before.

> And it could also be 'const' instead of __ro_after_init.

Then should be able to be a 'const' wrt  mips, m68k, arm platforms.
But should this even be changed, if this is going to be dropped off
eventually ?

> 
>>   	[VM_NONE]					= __P000,
>>   	[VM_READ]					= __P001,
>> @@ -120,9 +120,6 @@ pgprot_t protection_map[16] __ro_after_init = {
>>   	[VM_SHARED | VM_EXEC | VM_WRITE]		= __S110,
>>   	[VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]	= __S111
>>   };
>> -#endif
>> -
>> -#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   DECLARE_VM_GET_PAGE_PROT
>>   #endif	/* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
>>   

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "hch@infradead.org" <hch@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V4 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT
Date: Fri, 24 Jun 2022 11:06:44 +0530	[thread overview]
Message-ID: <e536bd05-dbfd-466b-582e-8a220421a8dc@arm.com> (raw)
In-Reply-To: <10aca763-2313-84bf-9200-6a6037fd748c@csgroup.eu>



On 6/24/22 10:52, Christophe Leroy wrote:
> 
> 
> Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
>> protection_map[] has already been moved inside those platforms which enable
> 
> Usually "already" means before your series.
> 
> Your series is the one that moves protection_map[] so I would have just 
> said "Now that protection_map[] has been moved inside those platforms 
> which enable ...."

Got it, will update the commit message.

> 
>> ARCH_HAS_VM_GET_PAGE_PROT. Hence generic protection_map[] array now can be
>> protected with CONFIG_ARCH_HAS_VM_GET_PAGE_PROT intead of __P000.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>   include/linux/mm.h | 2 +-
>>   mm/mmap.c          | 5 +----
>>   2 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 237828c2bae2..70d900f6df43 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -424,7 +424,7 @@ extern unsigned int kobjsize(const void *objp);
>>    * mapping from the currently active vm_flags protection bits (the
>>    * low four bits) to a page protection mask..
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   extern pgprot_t protection_map[16];
> 
> Is this declaration still needed ? I have the feeling that 
> protection_map[] is only used in mm/mmap.c now.

At this point generic protection_map[] array is still being used via
this declaration on many (!ARCH_HAS_VM_GET_PAGE_PROT) platforms such
as mips, m68k, arm etc.

> 
>>   #endif
>>   
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 55c30aee3999..43db3bd49071 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -101,7 +101,7 @@ static void unmap_region(struct mm_struct *mm,
>>    *								w: (no) no
>>    *								x: (yes) yes
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   pgprot_t protection_map[16] __ro_after_init = {
> 
> Should this be static, as it seems to now be used only in this file ?

This is being used in some platforms as mentioned before.

> And it could also be 'const' instead of __ro_after_init.

Then should be able to be a 'const' wrt  mips, m68k, arm platforms.
But should this even be changed, if this is going to be dropped off
eventually ?

> 
>>   	[VM_NONE]					= __P000,
>>   	[VM_READ]					= __P001,
>> @@ -120,9 +120,6 @@ pgprot_t protection_map[16] __ro_after_init = {
>>   	[VM_SHARED | VM_EXEC | VM_WRITE]		= __S110,
>>   	[VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]	= __S111
>>   };
>> -#endif
>> -
>> -#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   DECLARE_VM_GET_PAGE_PROT
>>   #endif	/* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
>>   

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"hch@infradead.org" <hch@infradead.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V4 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT
Date: Fri, 24 Jun 2022 11:06:44 +0530	[thread overview]
Message-ID: <e536bd05-dbfd-466b-582e-8a220421a8dc@arm.com> (raw)
In-Reply-To: <10aca763-2313-84bf-9200-6a6037fd748c@csgroup.eu>



On 6/24/22 10:52, Christophe Leroy wrote:
> 
> 
> Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
>> protection_map[] has already been moved inside those platforms which enable
> 
> Usually "already" means before your series.
> 
> Your series is the one that moves protection_map[] so I would have just 
> said "Now that protection_map[] has been moved inside those platforms 
> which enable ...."

Got it, will update the commit message.

> 
>> ARCH_HAS_VM_GET_PAGE_PROT. Hence generic protection_map[] array now can be
>> protected with CONFIG_ARCH_HAS_VM_GET_PAGE_PROT intead of __P000.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>   include/linux/mm.h | 2 +-
>>   mm/mmap.c          | 5 +----
>>   2 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 237828c2bae2..70d900f6df43 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -424,7 +424,7 @@ extern unsigned int kobjsize(const void *objp);
>>    * mapping from the currently active vm_flags protection bits (the
>>    * low four bits) to a page protection mask..
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   extern pgprot_t protection_map[16];
> 
> Is this declaration still needed ? I have the feeling that 
> protection_map[] is only used in mm/mmap.c now.

At this point generic protection_map[] array is still being used via
this declaration on many (!ARCH_HAS_VM_GET_PAGE_PROT) platforms such
as mips, m68k, arm etc.

> 
>>   #endif
>>   
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 55c30aee3999..43db3bd49071 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -101,7 +101,7 @@ static void unmap_region(struct mm_struct *mm,
>>    *								w: (no) no
>>    *								x: (yes) yes
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   pgprot_t protection_map[16] __ro_after_init = {
> 
> Should this be static, as it seems to now be used only in this file ?

This is being used in some platforms as mentioned before.

> And it could also be 'const' instead of __ro_after_init.

Then should be able to be a 'const' wrt  mips, m68k, arm platforms.
But should this even be changed, if this is going to be dropped off
eventually ?

> 
>>   	[VM_NONE]					= __P000,
>>   	[VM_READ]					= __P001,
>> @@ -120,9 +120,6 @@ pgprot_t protection_map[16] __ro_after_init = {
>>   	[VM_SHARED | VM_EXEC | VM_WRITE]		= __S110,
>>   	[VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]	= __S111
>>   };
>> -#endif
>> -
>> -#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   DECLARE_VM_GET_PAGE_PROT
>>   #endif	/* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
>>   


WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"hch@infradead.org" <hch@infradead.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-snps -arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V4 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT
Date: Fri, 24 Jun 2022 11:06:44 +0530	[thread overview]
Message-ID: <e536bd05-dbfd-466b-582e-8a220421a8dc@arm.com> (raw)
In-Reply-To: <10aca763-2313-84bf-9200-6a6037fd748c@csgroup.eu>



On 6/24/22 10:52, Christophe Leroy wrote:
> 
> 
> Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
>> protection_map[] has already been moved inside those platforms which enable
> 
> Usually "already" means before your series.
> 
> Your series is the one that moves protection_map[] so I would have just 
> said "Now that protection_map[] has been moved inside those platforms 
> which enable ...."

Got it, will update the commit message.

> 
>> ARCH_HAS_VM_GET_PAGE_PROT. Hence generic protection_map[] array now can be
>> protected with CONFIG_ARCH_HAS_VM_GET_PAGE_PROT intead of __P000.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>   include/linux/mm.h | 2 +-
>>   mm/mmap.c          | 5 +----
>>   2 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 237828c2bae2..70d900f6df43 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -424,7 +424,7 @@ extern unsigned int kobjsize(const void *objp);
>>    * mapping from the currently active vm_flags protection bits (the
>>    * low four bits) to a page protection mask..
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   extern pgprot_t protection_map[16];
> 
> Is this declaration still needed ? I have the feeling that 
> protection_map[] is only used in mm/mmap.c now.

At this point generic protection_map[] array is still being used via
this declaration on many (!ARCH_HAS_VM_GET_PAGE_PROT) platforms such
as mips, m68k, arm etc.

> 
>>   #endif
>>   
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 55c30aee3999..43db3bd49071 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -101,7 +101,7 @@ static void unmap_region(struct mm_struct *mm,
>>    *								w: (no) no
>>    *								x: (yes) yes
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   pgprot_t protection_map[16] __ro_after_init = {
> 
> Should this be static, as it seems to now be used only in this file ?

This is being used in some platforms as mentioned before.

> And it could also be 'const' instead of __ro_after_init.

Then should be able to be a 'const' wrt  mips, m68k, arm platforms.
But should this even be changed, if this is going to be dropped off
eventually ?

> 
>>   	[VM_NONE]					= __P000,
>>   	[VM_READ]					= __P001,
>> @@ -120,9 +120,6 @@ pgprot_t protection_map[16] __ro_after_init = {
>>   	[VM_SHARED | VM_EXEC | VM_WRITE]		= __S110,
>>   	[VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]	= __S111
>>   };
>> -#endif
>> -
>> -#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   DECLARE_VM_GET_PAGE_PROT
>>   #endif	/* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
>>   

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "hch@infradead.org" <hch@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V4 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT
Date: Fri, 24 Jun 2022 11:06:44 +0530	[thread overview]
Message-ID: <e536bd05-dbfd-466b-582e-8a220421a8dc@arm.com> (raw)
In-Reply-To: <10aca763-2313-84bf-9200-6a6037fd748c@csgroup.eu>



On 6/24/22 10:52, Christophe Leroy wrote:
> 
> 
> Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
>> protection_map[] has already been moved inside those platforms which enable
> 
> Usually "already" means before your series.
> 
> Your series is the one that moves protection_map[] so I would have just 
> said "Now that protection_map[] has been moved inside those platforms 
> which enable ...."

Got it, will update the commit message.

> 
>> ARCH_HAS_VM_GET_PAGE_PROT. Hence generic protection_map[] array now can be
>> protected with CONFIG_ARCH_HAS_VM_GET_PAGE_PROT intead of __P000.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>   include/linux/mm.h | 2 +-
>>   mm/mmap.c          | 5 +----
>>   2 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 237828c2bae2..70d900f6df43 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -424,7 +424,7 @@ extern unsigned int kobjsize(const void *objp);
>>    * mapping from the currently active vm_flags protection bits (the
>>    * low four bits) to a page protection mask..
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   extern pgprot_t protection_map[16];
> 
> Is this declaration still needed ? I have the feeling that 
> protection_map[] is only used in mm/mmap.c now.

At this point generic protection_map[] array is still being used via
this declaration on many (!ARCH_HAS_VM_GET_PAGE_PROT) platforms such
as mips, m68k, arm etc.

> 
>>   #endif
>>   
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 55c30aee3999..43db3bd49071 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -101,7 +101,7 @@ static void unmap_region(struct mm_struct *mm,
>>    *								w: (no) no
>>    *								x: (yes) yes
>>    */
>> -#ifdef __P000
>> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   pgprot_t protection_map[16] __ro_after_init = {
> 
> Should this be static, as it seems to now be used only in this file ?

This is being used in some platforms as mentioned before.

> And it could also be 'const' instead of __ro_after_init.

Then should be able to be a 'const' wrt  mips, m68k, arm platforms.
But should this even be changed, if this is going to be dropped off
eventually ?

> 
>>   	[VM_NONE]					= __P000,
>>   	[VM_READ]					= __P001,
>> @@ -120,9 +120,6 @@ pgprot_t protection_map[16] __ro_after_init = {
>>   	[VM_SHARED | VM_EXEC | VM_WRITE]		= __S110,
>>   	[VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]	= __S111
>>   };
>> -#endif
>> -
>> -#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>>   DECLARE_VM_GET_PAGE_PROT
>>   #endif	/* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
>>   

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-06-24  5:36 UTC|newest]

Thread overview: 379+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-24  4:43 [PATCH V4 00/26] mm/mmap: Drop __SXXX/__PXXX macros from across platforms Anshuman Khandual
2022-06-24  4:55 ` Anshuman Khandual
2022-06-24  4:43 ` Anshuman Khandual
2022-06-24  4:43 ` Anshuman Khandual
2022-06-24  4:43 ` Anshuman Khandual
2022-06-24  4:43 ` Anshuman Khandual
2022-06-24  4:43 ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 01/26] mm/mmap: Build protect protection_map[] with __P000 Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  5:08   ` Christoph Hellwig
2022-06-24  5:08     ` Christoph Hellwig
2022-06-24  5:08     ` Christoph Hellwig
2022-06-24  5:08     ` Christoph Hellwig
2022-06-24  5:08     ` Christoph Hellwig
2022-06-24  5:08     ` Christoph Hellwig
2022-06-24  5:08     ` Christoph Hellwig
2022-06-27  5:47   ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-24  4:43 ` [PATCH V4 02/26] mm/mmap: Define DECLARE_VM_GET_PAGE_PROT Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  5:09   ` Christoph Hellwig
2022-06-24  5:09     ` Christoph Hellwig
2022-06-24  5:09     ` Christoph Hellwig
2022-06-24  5:09     ` Christoph Hellwig
2022-06-24  5:09     ` Christoph Hellwig
2022-06-24  5:09     ` Christoph Hellwig
2022-06-24  5:09     ` Christoph Hellwig
2022-06-24  6:09     ` Anshuman Khandual
2022-06-24  6:21       ` Anshuman Khandual
2022-06-24  6:09       ` Anshuman Khandual
2022-06-24  6:09       ` Anshuman Khandual
2022-06-24  6:09       ` Anshuman Khandual
2022-06-24  6:09       ` Anshuman Khandual
2022-06-24  6:09       ` Anshuman Khandual
2022-06-24  5:28   ` Christophe Leroy
2022-06-24  5:28     ` Christophe Leroy
2022-06-24  5:28     ` Christophe Leroy
2022-06-24  5:28     ` Christophe Leroy
2022-06-24  5:28     ` Christophe Leroy
2022-06-24  5:28     ` Christophe Leroy
2022-06-24  5:28     ` Christophe Leroy
2022-06-24  5:28     ` Christophe Leroy
2022-06-24  6:11     ` Anshuman Khandual
2022-06-24  6:23       ` Anshuman Khandual
2022-06-24  6:11       ` Anshuman Khandual
2022-06-24  6:11       ` Anshuman Khandual
2022-06-24  6:11       ` Anshuman Khandual
2022-06-24  6:11       ` Anshuman Khandual
2022-06-24  6:11       ` Anshuman Khandual
2022-06-24  6:11       ` Anshuman Khandual
2022-06-27  5:47   ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-27  5:47     ` Christophe Leroy
2022-06-24  4:43 ` [PATCH V4 03/26] powerpc/mm: Move protection_map[] inside the platform Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  5:18   ` Christophe Leroy
2022-06-24  5:18     ` Christophe Leroy
2022-06-24  5:18     ` Christophe Leroy
2022-06-24  5:18     ` Christophe Leroy
2022-06-24  5:18     ` Christophe Leroy
2022-06-24  5:18     ` Christophe Leroy
2022-06-24  5:18     ` Christophe Leroy
2022-06-24  5:18     ` Christophe Leroy
2022-06-24  5:23     ` Anshuman Khandual
2022-06-24  5:35       ` Anshuman Khandual
2022-06-24  5:23       ` Anshuman Khandual
2022-06-24  5:23       ` Anshuman Khandual
2022-06-24  5:23       ` Anshuman Khandual
2022-06-24  5:23       ` Anshuman Khandual
2022-06-24  5:23       ` Anshuman Khandual
2022-06-24  5:23       ` Anshuman Khandual
2022-06-27  5:48   ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-24  4:43 ` [PATCH V4 04/26] sparc/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 05/26] arm64/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24 12:24   ` Catalin Marinas
2022-06-24 12:24     ` Catalin Marinas
2022-06-24 12:24     ` Catalin Marinas
2022-06-24 12:24     ` Catalin Marinas
2022-06-24 12:24     ` Catalin Marinas
2022-06-24 12:24     ` Catalin Marinas
2022-06-24 12:24     ` Catalin Marinas
2022-06-24  4:43 ` [PATCH V4 06/26] x86/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  5:10   ` Christoph Hellwig
2022-06-24  5:10     ` Christoph Hellwig
2022-06-24  5:10     ` Christoph Hellwig
2022-06-24  5:10     ` Christoph Hellwig
2022-06-24  5:10     ` Christoph Hellwig
2022-06-24  5:10     ` Christoph Hellwig
2022-06-24  5:10     ` Christoph Hellwig
2022-06-24  4:43 ` [PATCH V4 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  5:22   ` Christophe Leroy
2022-06-24  5:22     ` Christophe Leroy
2022-06-24  5:22     ` Christophe Leroy
2022-06-24  5:22     ` Christophe Leroy
2022-06-24  5:22     ` Christophe Leroy
2022-06-24  5:22     ` Christophe Leroy
2022-06-24  5:22     ` Christophe Leroy
2022-06-24  5:22     ` Christophe Leroy
2022-06-24  5:36     ` Anshuman Khandual [this message]
2022-06-24  5:48       ` Anshuman Khandual
2022-06-24  5:36       ` Anshuman Khandual
2022-06-24  5:36       ` Anshuman Khandual
2022-06-24  5:36       ` Anshuman Khandual
2022-06-24  5:36       ` Anshuman Khandual
2022-06-24  5:36       ` Anshuman Khandual
2022-06-24  5:36       ` Anshuman Khandual
2022-06-27  5:48   ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-24  4:43 ` [PATCH V4 08/26] microblaze/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  5:24   ` Christophe Leroy
2022-06-24  5:24     ` Christophe Leroy
2022-06-24  5:24     ` Christophe Leroy
2022-06-24  5:24     ` Christophe Leroy
2022-06-24  5:24     ` Christophe Leroy
2022-06-24  5:24     ` Christophe Leroy
2022-06-24  5:24     ` Christophe Leroy
2022-06-24  5:24     ` Christophe Leroy
2022-06-24  4:43 ` [PATCH V4 09/26] loongarch/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 10/26] openrisc/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-25  4:04   ` Stafford Horne
2022-06-25  4:04     ` Stafford Horne
2022-06-25  4:04     ` Stafford Horne
2022-06-25  4:04     ` Stafford Horne
2022-06-25  4:04     ` Stafford Horne
2022-06-25  4:04     ` Stafford Horne
2022-06-25  4:04     ` Stafford Horne
2022-06-24  4:43 ` [PATCH V4 11/26] extensa/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 12/26] hexagon/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 13/26] parisc/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 14/26] alpha/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 15/26] nios2/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 16/26] riscv/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  5:10   ` Christoph Hellwig
2022-06-24  5:10     ` Christoph Hellwig
2022-06-24  5:10     ` Christoph Hellwig
2022-06-24  5:10     ` Christoph Hellwig
2022-06-24  5:10     ` Christoph Hellwig
2022-06-24  5:10     ` Christoph Hellwig
2022-06-24  5:10     ` Christoph Hellwig
2022-06-24  4:43 ` [PATCH V4 17/26] csky/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-25  3:07   ` Guo Ren
2022-06-25  3:07     ` Guo Ren
2022-06-25  3:07     ` Guo Ren
2022-06-25  3:07     ` Guo Ren
2022-06-25  3:07     ` Guo Ren
2022-06-25  3:07     ` Guo Ren
2022-06-25  3:07     ` Guo Ren
2022-06-25  3:07     ` Guo Ren
2022-06-24  4:43 ` [PATCH V4 18/26] s390/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 19/26] ia64/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 20/26] mips/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 21/26] m68k/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 22/26] arc/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 23/26] arm/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 24/26] um/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 25/26] sh/mm: " Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43 ` [PATCH V4 26/26] mm/mmap: Drop ARCH_HAS_VM_GET_PAGE_PROT Anshuman Khandual
2022-06-24  4:55   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  4:43   ` Anshuman Khandual
2022-06-24  5:11   ` Christoph Hellwig
2022-06-24  5:11     ` Christoph Hellwig
2022-06-24  5:11     ` Christoph Hellwig
2022-06-24  5:11     ` Christoph Hellwig
2022-06-24  5:11     ` Christoph Hellwig
2022-06-24  5:11     ` Christoph Hellwig
2022-06-24  5:11     ` Christoph Hellwig
2022-06-24  5:29   ` Christophe Leroy
2022-06-24  5:29     ` Christophe Leroy
2022-06-24  5:29     ` Christophe Leroy
2022-06-24  5:29     ` Christophe Leroy
2022-06-24  5:29     ` Christophe Leroy
2022-06-24  5:29     ` Christophe Leroy
2022-06-24  5:29     ` Christophe Leroy
2022-06-24  5:29     ` Christophe Leroy
2022-06-27  5:48   ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-27  5:48     ` Christophe Leroy
2022-06-24  5:12 ` [PATCH V4 00/26] mm/mmap: Drop __SXXX/__PXXX macros from across platforms Christoph Hellwig
2022-06-24  5:12   ` Christoph Hellwig
2022-06-24  5:12   ` Christoph Hellwig
2022-06-24  5:12   ` Christoph Hellwig
2022-06-24  5:12   ` Christoph Hellwig
2022-06-24  5:12   ` Christoph Hellwig
2022-06-24  5:12   ` Christoph Hellwig
2022-06-24  5:20   ` Anshuman Khandual
2022-06-24  5:32     ` Anshuman Khandual
2022-06-24  5:20     ` Anshuman Khandual
2022-06-24  5:20     ` Anshuman Khandual
2022-06-24  5:20     ` Anshuman Khandual
2022-06-24  5:20     ` Anshuman Khandual
2022-06-24  5:20     ` Anshuman Khandual
2022-06-24  5:21     ` Christoph Hellwig
2022-06-24  5:21       ` Christoph Hellwig
2022-06-24  5:21       ` Christoph Hellwig
2022-06-24  5:21       ` Christoph Hellwig
2022-06-24  5:21       ` Christoph Hellwig
2022-06-24  5:21       ` Christoph Hellwig
2022-06-24  5:21       ` Christoph Hellwig

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=e536bd05-dbfd-466b-582e-8a220421a8dc@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=hch@infradead.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-ia64@vg \
    --cc=linux-mm@kvack.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=openrisc@lists.librecores.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=x86@kernel.org \
    /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.