Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info

[Christophe Leroy]

Le 02/03/2024 à 02:51, Kees Cook a écrit :
> On Sat, Mar 02, 2024 at 12:47:08AM +, Edgecombe, Rick P wrote:
>> On Wed, 2024-02-28 at 09:21 -0800, Kees Cook wrote:
>>> I totally understand. If the "uninitialized" warnings were actually
>>> reliable, I would agree. I look at it this way:
>>>
>>> - initializations can be missed either in static initializers or via
>>>    run time initializers. (So the risk of mistake here is matched --
>>>    though I'd argue it's easier to *find* static initializers when
>>> adding
>>>    new struct members.)
>>> - uninitialized warnings are inconsistent (this becomes an unknown
>>> risk)
>>> - when a run time initializer is missed, the contents are whatever
>>> was
>>>    on the stack (high risk)
>>> - what a static initializer is missed, the content is 0 (low risk)
>>>
>>> I think unambiguous state (always 0) is significantly more important
>>> for
>>> the safety of the system as a whole. Yes, individual cases maybe bad
>>> ("what uid should this be? root?!") but from a general memory safety
>>> perspective the value doesn't become potentially influenced by order
>>> of
>>> operations, leftover stack memory, etc.
>>>
>>> I'd agree, lifting everything into a static initializer does seem
>>> cleanest of all the choices.
>>
>> Hi Kees,
>>
>> Well, I just gave this a try. It is giving me flashbacks of when I last
>> had to do a tree wide change that I couldn't fully test and the
>> breakage was caught by Linus.
> 
> Yeah, testing isn't fun for these kinds of things. This is traditionally
> why the "obviously correct" changes tend to have an easier time landing
> (i.e. adding "= {}" to all of them).
> 
>> Could you let me know if you think this is additionally worthwhile
>> cleanup outside of the guard gap improvements of this series? Because I
>> was thinking a more cowardly approach could be a new vm_unmapped_area()
>> variant that takes the new start gap member as a separate argument
>> outside of struct vm_unmapped_area_info. It would be kind of strange to
>> keep them separate, but it would be less likely to bump something.
> 
> I think you want a new member -- AIUI, that's what that struct is for.
> 
> Looking at this resulting set of patches, I do kinda think just adding
> the "= {}" in a single patch is more sensible. Having to split things
> that are know at the top of the function from the stuff known at the
> existing initialization time is rather awkward.
> 
> Personally, I think a single patch that sets "= {}" for all of them and
> drop the all the "= 0" or "= NULL" assignments would be the cleanest way
> to go.

I agree with Kees, set = {} and drop all the "something = 0;" stuff.

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

Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info

[Christophe Leroy]

Le 28/02/2024 à 18:01, Edgecombe, Rick P a écrit :
> On Wed, 2024-02-28 at 13:22 +0000, Christophe Leroy wrote:
>>> Any preference? Or maybe am I missing your point and talking
>>> nonsense?
>>>
>>
>> So my preference would go to the addition of:
>>
>>  info.new_field = 0;
>>
>> But that's very minor and if you think it is easier to manage and
>> maintain by performing {} initialisation at declaration, lets go for
>> that.
> 
> Appreciate the clarification and help getting this right. I'm thinking
> Kees' and now Kirill's point about this patch resulting in unnecessary
> manual zero initialization of the structs is probably something that
> needs to be addressed.
> 
> If I created a bunch of patches to change each call site, I think the
> the best is probably to do the designated field zero initialization
> way.
> 
> But I can do something for powerpc special if you want. I'll first try
> with powerpc matching the others, and if it seems objectionable, please
> let me know.
> 

My comments were generic, it was not powerpc oriented. Please keep 
powerpc as similar as possible with others.

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

Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info

[Christophe Leroy]

Le 27/02/2024 à 21:25, Edgecombe, Rick P a écrit :
> On Tue, 2024-02-27 at 18:16 +0000, Christophe Leroy wrote:
>>>> Why doing a full init of the struct when all fields are re-
>>>> written a few
>>>> lines after ?
>>>
>>> It's a nice change for robustness and makes future changes easier.
>>> It's
>>> not actually wasteful since the compiler will throw away all
>>> redundant
>>> stores.
>>
>> Well, I tend to dislike default init at declaration because it often
>> hides missed real init. When a field is not initialized GCC should
>> emit
>> a Warning, at least when built with W=2 which sets
>> -Wmissing-field-initializers ?
> 
> Sorry, I'm not following where you are going with this. There aren't
> any struct vm_unmapped_area_info users that use initializers today, so
> that warning won't apply in this case. Meanwhile, designated style
> struct initialization (which would zero new members) is very common, as
> well as not get anything checked by that warning. Anything with this
> many members is probably going to use the designated style.
> 
> If we are optimizing to avoid bugs, the way this struct is used today
> is not great. It is essentially being used as an argument passer.
> Normally when a function signature changes, but a caller is missed, of
> course the compiler will notice loudly. But not here. So I think
> probably zero initializing it is safer than being setup to pass
> garbage.

No worry, if everybody thinks that init at declaration is worth it in 
that case it is OK for me and I'm not going to ask for something special 
on powerpc, my comment was more general allthough I used powerpc as an 
exemple.

My worry with initialisation at declaration is it often hides missing 
assignments. Let's take following simple exemple:

char *colour(int num)
{
char *name;

if (num == 0) {
name = "black";
} else if (num == 1) {
name = "white";
} else if (num == 2) {
} else {
name = "no colour";
}

return name;
}


Here, GCC warns about a missing initialisation of variable 'name'.

But if I declare it as

char *name = "no colour";

Then GCC won't warn anymore that we are missing a value for when num is 2.

During my life I have so many times spent huge amount of time 
investigating issues and bugs due to missing assignments that were going 
undetected due to default initialisation at declaration.

> 
> I'm trying to figure out what to do here. If I changed it so that just
> powerpc set the new field manually, then the convention across the
> kernel would be for everything to be default zero, and future other new
> parameters could have a greater chance of turning into garbage on
> powerpc. Since it could be easy to miss that powerpc was special. Would
> you prefer it?
> 
> Or maybe I could try a new vm_unmapped_area() that takes the extra
> argument separately? The old callers could call the old function and
> not need any arch updates. It all seems strange though, because
> automatic zero initializing struct members is so common in the kernel.
> But it also wouldn't add the cleanup Kees was pointing out. Hmm.
> 
> Any preference? Or maybe am I missing your point and talking nonsense?
> 

So my preference would go to the addition of:

info.new_field = 0;

But that's very minor and if you think it is easier to manage and 
maintain by performing {} initialisation at declaration, lets go for that.

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

Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info

[Christophe Leroy]

Le 27/02/2024 à 19:07, Kees Cook a écrit :
> On Tue, Feb 27, 2024 at 07:02:59AM +0000, Christophe Leroy wrote:
>>
>>
>> Le 26/02/2024 à 20:09, Rick Edgecombe a écrit :
>>> Future changes will need to add a field to struct vm_unmapped_area_info.
>>> This would cause trouble for any archs that don't initialize the
>>> struct. Currently every user sets each field, so if new fields are
>>> added, the core code parsing the struct will see garbage in the new
>>> field.
>>>
>>> It could be possible to initialize the new field for each arch to 0, but
>>> instead simply inialize the field with a C99 struct inializing syntax.
>>
>> Why doing a full init of the struct when all fields are re-written a few
>> lines after ?
> 
> It's a nice change for robustness and makes future changes easier. It's
> not actually wasteful since the compiler will throw away all redundant
> stores.

Well, I tend to dislike default init at declaration because it often 
hides missed real init. When a field is not initialized GCC should emit 
a Warning, at least when built with W=2 which sets 
-Wmissing-field-initializers ?

> 
>> If I take the exemple of powerpc function slice_find_area_bottomup():
>>
>>  struct vm_unmapped_area_info info;
>>
>>  info.flags = 0;
>>  info.length = len;
>>  info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
>>  info.align_offset = 0;
> 
> But one cleanup that is possible from explicitly zero-initializing the
> whole structure would be dropping all the individual "= 0" assignments.
> :)
> 

Sure if we decide to go that direction all those 0 assignments void.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 1/4] arch: consolidate existing CONFIG_PAGE_SIZE_*KB definitions

[Christophe Leroy]

Le 27/02/2024 à 16:40, Arnd Bergmann a écrit :
> On Mon, Feb 26, 2024, at 17:55, Samuel Holland wrote:
>> On 2024-02-26 10:14 AM, Arnd Bergmann wrote:
>>>   
>>> +config HAVE_PAGE_SIZE_4KB
>>> +   bool
>>> +
>>> +config HAVE_PAGE_SIZE_8KB
>>> +   bool
>>> +
>>> +config HAVE_PAGE_SIZE_16KB
>>> +   bool
>>> +
>>> +config HAVE_PAGE_SIZE_32KB
>>> +   bool
>>> +
>>> +config HAVE_PAGE_SIZE_64KB
>>> +   bool
>>> +
>>> +config HAVE_PAGE_SIZE_256KB
>>> +   bool
>>> +
>>> +choice
>>> +   prompt "MMU page size"
>>
>> Should this have some generic help text (at least a warning about
>> compatibility)?
> 
> Good point. I've added some of this now, based on the mips
> text with some generalizations for other architectures:
> 
> config PAGE_SIZE_4KB
>  bool "4KiB pages"
>  depends on HAVE_PAGE_SIZE_4KB
>  help
>This option select the standard 4KiB Linux page size and the only
>available option on many architectures. Using 4KiB page size will
>minimize memory consumption and is therefore recommended for low
>memory systems.
>Some software that is written for x86 systems makes incorrect
>assumptions about the page size and only runs on 4KiB pages.
> 
> config PAGE_SIZE_8KB
>  bool "8KiB pages"
>  depends on HAVE_PAGE_SIZE_8KB
>  help
>This option is the only supported page size on a few older
>processors, and can be slightly faster than 4KiB pages.
> 
> config PAGE_SIZE_16KB
>  bool "16KiB pages"
>  depends on HAVE_PAGE_SIZE_16KB
>  help
>This option is usually a good compromise between memory
>consumption and performance for typical desktop and server
>workloads, often saving a level of page table lookups compared
>to 4KB pages as well as reducing TLB pressure and overhead of
>per-page operations in the kernel at the expense of a larger
>page cache.
> 
> config PAGE_SIZE_32KB
>  bool "32KiB pages"
>  depends on HAVE_PAGE_SIZE_32KB
>Using 32KiB page size will result in slightly higher performance
>kernel at the price of higher memory consumption compared to
>16KiB pages.  This option is available only on cnMIPS cores.
>Note that you will need a suitable Linux distribution to
>support this.
> 
> config PAGE_SIZE_64KB
>  bool "64KiB pages"
>  depends on HAVE_PAGE_SIZE_64KB
>Using 64KiB page size will result in slightly higher performance
>kernel at the price of much higher memory consumption compared to
>4KiB or 16KiB pages.
>This is not suitable for general-purpose workloads but the
>better performance may be worth the cost for certain types of
>supercomputing or database applications that work mostly with
>large in-memory data rather than small files.
> 
> config PAGE_SIZE_256KB
>  bool "256KiB pages"
>  depends on HAVE_PAGE_SIZE_256KB
>  help
>256KB pages have little practical value due to their extreme
>memory usage.


For 256K pages, powerpc has the following help. I think you should have 
it too:

  The kernel will only be able to run applications that have been
  compiled with '-zmax-page-size' set to 256K (the default is 64K) using
  binutils later than 2.17.50.0.3, or by patching the ELF_MAXPAGESIZE
  definition from 0x1 to 0x4 in older versions.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info

[Christophe Leroy]

Le 26/02/2024 à 20:09, Rick Edgecombe a écrit :
> Future changes will need to add a field to struct vm_unmapped_area_info.
> This would cause trouble for any archs that don't initialize the
> struct. Currently every user sets each field, so if new fields are
> added, the core code parsing the struct will see garbage in the new
> field.
> 
> It could be possible to initialize the new field for each arch to 0, but
> instead simply inialize the field with a C99 struct inializing syntax.

Why doing a full init of the struct when all fields are re-written a few 
lines after ?

If I take the exemple of powerpc function slice_find_area_bottomup():

struct vm_unmapped_area_info info;

info.flags = 0;
info.length = len;
info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
info.align_offset = 0;

For me it looks better to just add:

info.new_field = 0; /* or whatever value it needs to have */

Christophe


> 
> Cc: linux...@kvack.org
> Cc: linux-al...@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-c...@vger.kernel.org
> Cc: loonga...@lists.linux.dev
> Cc: linux-m...@vger.kernel.org
> Cc: linux-par...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: sparcli...@vger.kernel.org
> Cc: x...@kernel.org
> Suggested-by: Kirill A. Shutemov 
> Signed-off-by: Rick Edgecombe 
> Link: 
> https://lore.kernel.org/lkml/3ynogxcgokc6i6xojbxzzwqectg472laes24u7jmtktlxcch5e@dfytra3ia3zc/#t
> ---
> Hi archs,
> 
> For some context, this is part of a larger series to improve shadow stack
> guard gaps. It involves plumbing a new field via
> struct vm_unmapped_area_info. The first user is x86, but arm and riscv may
> likely use it as well. The change is compile tested only for non-x86 but
> seems like a relatively safe one.
> 
> Thanks,
> 
> Rick
> 
> v2:
>   - New patch
> ---
>   arch/alpha/kernel/osf_sys.c  | 2 +-
>   arch/arc/mm/mmap.c   | 2 +-
>   arch/arm/mm/mmap.c   | 4 ++--
>   arch/csky/abiv1/mmap.c   | 2 +-
>   arch/loongarch/mm/mmap.c | 2 +-
>   arch/mips/mm/mmap.c  | 2 +-
>   arch/parisc/kernel/sys_parisc.c  | 2 +-
>   arch/powerpc/mm/book3s64/slice.c | 4 ++--
>   arch/s390/mm/hugetlbpage.c   | 4 ++--
>   arch/s390/mm/mmap.c  | 4 ++--
>   arch/sh/mm/mmap.c| 4 ++--
>   arch/sparc/kernel/sys_sparc_32.c | 2 +-
>   arch/sparc/kernel/sys_sparc_64.c | 4 ++--
>   arch/sparc/mm/hugetlbpage.c  | 4 ++--
>   arch/x86/kernel/sys_x86_64.c | 4 ++--
>   arch/x86/mm/hugetlbpage.c| 4 ++--
>   fs/hugetlbfs/inode.c | 4 ++--
>   mm/mmap.c| 4 ++--
>   18 files changed, 29 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
> index 5db88b627439..dd6801bb9240 100644
> --- a/arch/alpha/kernel/osf_sys.c
> +++ b/arch/alpha/kernel/osf_sys.c
> @@ -1218,7 +1218,7 @@ static unsigned long
>   arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
>unsigned long limit)
>   {
> - struct vm_unmapped_area_info info;
> + struct vm_unmapped_area_info info = {};
>   
>   info.flags = 0;
>   info.length = len;
> diff --git a/arch/arc/mm/mmap.c b/arch/arc/mm/mmap.c
> index 3c1c7ae73292..6549b3375f54 100644
> --- a/arch/arc/mm/mmap.c
> +++ b/arch/arc/mm/mmap.c
> @@ -27,7 +27,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long 
> addr,
>   {
>   struct mm_struct *mm = current->mm;
>   struct vm_area_struct *vma;
> - struct vm_unmapped_area_info info;
> + struct vm_unmapped_area_info info = {};
>   
>   /*
>* We enforce the MAP_FIXED case.
> diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
> index a0f8a0ca0788..525795578c29 100644
> --- a/arch/arm/mm/mmap.c
> +++ b/arch/arm/mm/mmap.c
> @@ -34,7 +34,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long 
> addr,
>   struct vm_area_struct *vma;
>   int do_align = 0;
>   int aliasing = cache_is_vipt_aliasing();
> - struct vm_unmapped_area_info info;
> + struct vm_unmapped_area_info info = {};
>   
>   /*
>* We only need to do colour alignment if either the I or D
> @@ -87,7 +87,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const 
> unsigned long addr0,
>   unsigned long addr = addr0;
>   int do_align = 0;
>   int aliasing = cache_is_vipt_aliasing();
> - struct vm_unmapped_area_info info;
> + struct vm_unmapped_area_info info = {};
>   
>   /*
>* We only need to do colour alignment if either the I or D
> diff --git a/arch/csky/abiv1/mmap.c b/arch/csky/abiv1/mmap.c
> index 6792aca4..726659d41fa9 100644
> --- a/arch/csky/abiv1/mmap.c
> +++ b/arch/csky/abiv1/mmap.c
> @@ -28,7 +28,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long 
> addr,
>   struct mm_struct *mm = 

Re: [PATCH 2/4] arch: simplify architecture specific page size configuration

[Christophe Leroy]

Le 26/02/2024 à 17:14, Arnd Bergmann a écrit :
> From: Arnd Bergmann 
> 
> arc, arm64, parisc and powerpc all have their own Kconfig symbols
> in place of the common CONFIG_PAGE_SIZE_4KB symbols. Change these
> so the common symbols are the ones that are actually used, while
> leaving the arhcitecture specific ones as the user visible
> place for configuring it, to avoid breaking user configs.
> 
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Christophe Leroy  (powerpc32)

> ---
>   arch/arc/Kconfig  |  3 +++
>   arch/arc/include/uapi/asm/page.h  |  6 ++
>   arch/arm64/Kconfig| 29 +
>   arch/arm64/include/asm/page-def.h |  2 +-
>   arch/parisc/Kconfig   |  3 +++
>   arch/parisc/include/asm/page.h| 10 +-
>   arch/powerpc/Kconfig  | 31 ++-
>   arch/powerpc/include/asm/page.h   |  2 +-
>   scripts/gdb/linux/constants.py.in |  2 +-
>   scripts/gdb/linux/mm.py   |  2 +-
>   10 files changed, 32 insertions(+), 58 deletions(-)
> 
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 1b0483c51cc1..4092bec198be 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -284,14 +284,17 @@ choice
>   
>   config ARC_PAGE_SIZE_8K
>   bool "8KB"
> + select HAVE_PAGE_SIZE_8KB
>   help
> Choose between 8k vs 16k
>   
>   config ARC_PAGE_SIZE_16K
> + select HAVE_PAGE_SIZE_16KB
>   bool "16KB"
>   
>   config ARC_PAGE_SIZE_4K
>   bool "4KB"
> + select HAVE_PAGE_SIZE_4KB
>   depends on ARC_MMU_V3 || ARC_MMU_V4
>   
>   endchoice
> diff --git a/arch/arc/include/uapi/asm/page.h 
> b/arch/arc/include/uapi/asm/page.h
> index 2a4ad619abfb..7fd9e741b527 100644
> --- a/arch/arc/include/uapi/asm/page.h
> +++ b/arch/arc/include/uapi/asm/page.h
> @@ -13,10 +13,8 @@
>   #include 
>   
>   /* PAGE_SHIFT determines the page size */
> -#if defined(CONFIG_ARC_PAGE_SIZE_16K)
> -#define PAGE_SHIFT 14
> -#elif defined(CONFIG_ARC_PAGE_SIZE_4K)
> -#define PAGE_SHIFT 12
> +#ifdef __KERNEL__
> +#define PAGE_SHIFT CONFIG_PAGE_SHIFT
>   #else
>   /*
>* Default 8k
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index aa7c1d435139..29290b8cb36d 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -277,27 +277,21 @@ config 64BIT
>   config MMU
>   def_bool y
>   
> -config ARM64_PAGE_SHIFT
> - int
> - default 16 if ARM64_64K_PAGES
> - default 14 if ARM64_16K_PAGES
> - default 12
> -
>   config ARM64_CONT_PTE_SHIFT
>   int
> - default 5 if ARM64_64K_PAGES
> - default 7 if ARM64_16K_PAGES
> + default 5 if PAGE_SIZE_64KB
> + default 7 if PAGE_SIZE_16KB
>   default 4
>   
>   config ARM64_CONT_PMD_SHIFT
>   int
> - default 5 if ARM64_64K_PAGES
> - default 5 if ARM64_16K_PAGES
> + default 5 if PAGE_SIZE_64KB
> + default 5 if PAGE_SIZE_16KB
>   default 4
>   
>   config ARCH_MMAP_RND_BITS_MIN
> - default 14 if ARM64_64K_PAGES
> - default 16 if ARM64_16K_PAGES
> + default 14 if PAGE_SIZE_64KB
> + default 16 if PAGE_SIZE_16KB
>   default 18
>   
>   # max bits determined by the following formula:
> @@ -1259,11 +1253,13 @@ choice
>   
>   config ARM64_4K_PAGES
>   bool "4KB"
> + select HAVE_PAGE_SIZE_4KB
>   help
> This feature enables 4KB pages support.
>   
>   config ARM64_16K_PAGES
>   bool "16KB"
> + select HAVE_PAGE_SIZE_16KB
>   help
> The system will use 16KB pages support. AArch32 emulation
> requires applications compiled with 16K (or a multiple of 16K)
> @@ -1271,6 +1267,7 @@ config ARM64_16K_PAGES
>   
>   config ARM64_64K_PAGES
>   bool "64KB"
> + select HAVE_PAGE_SIZE_64KB
>   help
> This feature enables 64KB pages support (4KB by default)
> allowing only two levels of page tables and faster TLB
> @@ -1291,19 +1288,19 @@ choice
>   
>   config ARM64_VA_BITS_36
>   bool "36-bit" if EXPERT
> - depends on ARM64_16K_PAGES
> + depends on PAGE_SIZE_16KB
>   
>   config ARM64_VA_BITS_39
>   bool "39-bit"
> - depends on ARM64_4K_PAGES
> + depends on PAGE_SIZE_4KB
>   
>   config ARM64_VA_BITS_42
>   bool "42-bit"
> - depends on ARM64_64K_PAGES
> + depends on PAGE_SIZE_64KB
>   
>   config ARM64_VA_BITS_47
>   bool "47-bit"
> - depends on ARM64_16K_PAGES
> + depends on PAGE_SIZE_16KB
>   
>   config ARM64_VA_BITS_

Re: [PATCH 1/4] arch: consolidate existing CONFIG_PAGE_SIZE_*KB definitions

[Christophe Leroy]

Le 26/02/2024 à 17:14, Arnd Bergmann a écrit :
> From: Arnd Bergmann 
> 
> These four architectures define the same Kconfig symbols for configuring
> the page size. Move the logic into a common place where it can be shared
> with all other architectures.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>   arch/Kconfig  | 58 +--
>   arch/hexagon/Kconfig  | 25 +++--
>   arch/hexagon/include/asm/page.h   |  6 +---
>   arch/loongarch/Kconfig| 21 ---
>   arch/loongarch/include/asm/page.h | 10 +-
>   arch/mips/Kconfig | 58 +++
>   arch/mips/include/asm/page.h  | 16 +
>   arch/sh/include/asm/page.h| 13 +--
>   arch/sh/mm/Kconfig| 42 +++---
>   9 files changed, 88 insertions(+), 161 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index a5af0edd3eb8..237cea01ed9b 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -1078,17 +1078,71 @@ config HAVE_ARCH_COMPAT_MMAP_BASES
> and vice-versa 32-bit applications to call 64-bit mmap().
> Required for applications doing different bitness syscalls.
>   
> +config HAVE_PAGE_SIZE_4KB
> + bool
> +
> +config HAVE_PAGE_SIZE_8KB
> + bool
> +
> +config HAVE_PAGE_SIZE_16KB
> + bool
> +
> +config HAVE_PAGE_SIZE_32KB
> + bool
> +
> +config HAVE_PAGE_SIZE_64KB
> + bool
> +
> +config HAVE_PAGE_SIZE_256KB
> + bool
> +
> +choice
> + prompt "MMU page size"
> +

That's a nice re-factor.

The only drawback I see is that we are loosing several interesting 
arch-specific comments/help text. Don't know if there could be an easy 
way to keep them.


> +config PAGE_SIZE_4KB
> + bool "4KB pages"
> + depends on HAVE_PAGE_SIZE_4KB
> +
> +config PAGE_SIZE_8KB
> + bool "8KB pages"
> + depends on HAVE_PAGE_SIZE_8KB
> +
> +config PAGE_SIZE_16KB
> + bool "16KB pages"
> + depends on HAVE_PAGE_SIZE_16KB
> +
> +config PAGE_SIZE_32KB
> + bool "32KB pages"
> + depends on HAVE_PAGE_SIZE_32KB
> +
> +config PAGE_SIZE_64KB
> + bool "64KB pages"
> + depends on HAVE_PAGE_SIZE_64KB
> +
> +config PAGE_SIZE_256KB
> + bool "256KB pages"
> + depends on HAVE_PAGE_SIZE_256KB

Hexagon seem to also use CONFIG_PAGE_SIZE_1MB ?

> +
> +endchoice
> +
>   config PAGE_SIZE_LESS_THAN_64KB
>   def_bool y
> - depends on !ARM64_64K_PAGES
>   depends on !PAGE_SIZE_64KB
> - depends on !PARISC_PAGE_SIZE_64KB
>   depends on PAGE_SIZE_LESS_THAN_256KB
>   
>   config PAGE_SIZE_LESS_THAN_256KB
>   def_bool y
>   depends on !PAGE_SIZE_256KB
>   
> +config PAGE_SHIFT
> + int
> + default 12 if PAGE_SIZE_4KB
> + default 13 if PAGE_SIZE_8KB
> + default 14 if PAGE_SIZE_16KB
> + default 15 if PAGE_SIZE_32KB
> + default 16 if PAGE_SIZE_64KB
> + default 18 if PAGE_SIZE_256KB
> +
>   # This allows to use a set of generic functions to determine mmap base
>   # address by giving priority to top-down scheme only if the process
>   # is not in legacy mode (compat task, unlimited stack size or
> diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
> index a880ee067d2e..aac46ee1a000 100644
> --- a/arch/hexagon/Kconfig
> +++ b/arch/hexagon/Kconfig
> @@ -8,6 +8,11 @@ config HEXAGON
>   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
>   select ARCH_NO_PREEMPT
>   select DMA_GLOBAL_POOL
> + select FRAME_POINTER
> + select HAVE_PAGE_SIZE_4KB
> + select HAVE_PAGE_SIZE_16KB
> + select HAVE_PAGE_SIZE_64KB
> + select HAVE_PAGE_SIZE_256KB
>   # Other pending projects/to-do items.
>   # select HAVE_REGS_AND_STACK_ACCESS_API
>   # select HAVE_HW_BREAKPOINT if PERF_EVENTS
> @@ -120,26 +125,6 @@ config NR_CPUS
> This is purely to save memory - each supported CPU adds
> approximately eight kilobytes to the kernel image.
>   
> -choice
> - prompt "Kernel page size"
> - default PAGE_SIZE_4KB
> - help
> -   Changes the default page size; use with caution.
> -
> -config PAGE_SIZE_4KB
> - bool "4KB"
> -
> -config PAGE_SIZE_16KB
> - bool "16KB"
> -
> -config PAGE_SIZE_64KB
> - bool "64KB"
> -
> -config PAGE_SIZE_256KB
> - bool "256KB"
> -
> -endchoice
> -
>   source "kernel/Kconfig.hz"
>   
>   endmenu
> diff --git a/arch/hexagon/include/asm/page.h b/arch/hexagon/include/asm/page.h
> index 10f1bc07423c..65c9bac639fa 100644
> --- a/arch/hexagon/include/asm/page.h
> +++ b/arch/hexagon/include/asm/page.h
> @@ -13,27 +13,22 @@
>   /*  This is probably not the most graceful way to handle this.  */
>   
>   #ifdef CONFIG_PAGE_SIZE_4KB
> -#define PAGE_SHIFT 12
>   #define HEXAGON_L1_PTE_SIZE __HVM_PDE_S_4KB
>   #endif
>   
>   #ifdef CONFIG_PAGE_SIZE_16KB
> -#define PAGE_SHIFT 14
>   #define HEXAGON_L1_PTE_SIZE __HVM_PDE_S_16KB
>   #endif
>   
>   #ifdef CONFIG_PAGE_SIZE_64KB
> -#define PAGE_SHIFT 16
>   #define HEXAGON_L1_PTE_SIZE __HVM_PDE_S_64KB
>   

Re: [PATCH 4/4] vdso: avoid including asm/page.h

[Christophe Leroy]

Le 26/02/2024 à 17:14, Arnd Bergmann a écrit :
> From: Arnd Bergmann 
> 
> The recent change to the vdso_data_store broke building compat VDSO
> on at least arm64 because it includes headers outside of the include/vdso/
> namespace:

I understand that powerpc64 also has an issue, see 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20231221120410.2226678-1-...@ellerman.id.au/

> 
> In file included from arch/arm64/include/asm/lse.h:5,
>   from arch/arm64/include/asm/cmpxchg.h:14,
>   from arch/arm64/include/asm/atomic.h:16,
>   from include/linux/atomic.h:7,
>   from include/asm-generic/bitops/atomic.h:5,
>   from arch/arm64/include/asm/bitops.h:25,
>   from include/linux/bitops.h:68,
>   from arch/arm64/include/asm/memory.h:209,
>   from arch/arm64/include/asm/page.h:46,
>   from include/vdso/datapage.h:22,
>   from lib/vdso/gettimeofday.c:5,
>   from :
> arch/arm64/include/asm/atomic_ll_sc.h:298:9: error: unknown type name 'u128'
>298 | u128 full;
> 
> Use an open-coded page size calculation based on the new CONFIG_PAGE_SHIFT
> Kconfig symbol instead.
> 
> Reported-by: Linux Kernel Functional Testing 
> Fixes: a0d2fcd62ac2 ("vdso/ARM: Make union vdso_data_store available for all 
> architectures")
> Link: 
> https://lore.kernel.org/lkml/ca+g9fytrxxm_ko9fnpz3xarxhv7ud_yqp-teupqrnrhu+_0...@mail.gmail.com/
> Signed-off-by: Arnd Bergmann 
> ---
>   include/vdso/datapage.h | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/include/vdso/datapage.h b/include/vdso/datapage.h
> index 7ba44379a095..2c39a67d7e23 100644
> --- a/include/vdso/datapage.h
> +++ b/include/vdso/datapage.h
> @@ -19,8 +19,6 @@
>   #include 
>   #include 
>   
> -#include 
> -
>   #ifdef CONFIG_ARCH_HAS_VDSO_DATA
>   #include 
>   #else
> @@ -128,7 +126,7 @@ extern struct vdso_data _timens_data[CS_BASES] 
> __attribute__((visibility("hidden
>*/
>   union vdso_data_store {
>   struct vdso_datadata[CS_BASES];
> - u8  page[PAGE_SIZE];
> + u8  page[1ul << CONFIG_PAGE_SHIFT];

Usually 1UL is used (capital letter)

Maybe better to (re)define PAGE_SIZE instead, something like:

#define PAGE_SIZE (1UL << CONFIG_PAGE_SHIFT)


>   };
>   
>   /*
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 15/22] arch: vdso: consolidate gettime prototypes

[Christophe Leroy]

Le 09/11/2023 à 11:18, Michael Ellerman a écrit :
> "Arnd Bergmann"  writes:
>> On Wed, Nov 8, 2023, at 19:31, Christophe Leroy wrote:
>>> Le 08/11/2023 à 13:58, Arnd Bergmann a écrit :
>>
>>> powerpc has functions doing more or less the same, they are called
>>> __c_kernel_clock_gettime() and alike with their prototypes siting in
>>> arch/powerpc/include/asm/vdso/gettimeofday.h
>>>
>>> Should those prototypes be moved to include/vdso/gettime.h too and
>>> eventually renamed, or are they considered too powerpc specific ?
>>
>> I don't actually know, my initial interpretation was that
>> these function names are part of the user ABI for the vdso,
>> but I never looked closely enough at how vdso works to
>> be sure what the actual ABI is.
> 
> AFAIK the ABI is just the symbols we export, as defined in the linker
> script:
> 
> /*
>   * This controls what symbols we export from the DSO.
>   */
> VERSION
> {
>   VDSO_VERSION_STRING {
>   global:
>   __kernel_get_syscall_map;
>   __kernel_gettimeofday;
>   __kernel_clock_gettime;
>   __kernel_clock_getres;
>   __kernel_get_tbfreq;
>   __kernel_sync_dicache;
>   __kernel_sigtramp_rt64;
>   __kernel_getcpu;
>   __kernel_time;
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vdso/vdso64.lds.S?h=v6.6&#

Re: [PATCH 15/22] arch: vdso: consolidate gettime prototypes

[Christophe Leroy]

Le 08/11/2023 à 20:37, Arnd Bergmann a écrit :
> On Wed, Nov 8, 2023, at 19:31, Christophe Leroy wrote:
>> Le 08/11/2023 à 13:58, Arnd Bergmann a écrit :
> 
>> powerpc has functions doing more or less the same, they are called
>> __c_kernel_clock_gettime() and alike with their prototypes siting in
>> arch/powerpc/include/asm/vdso/gettimeofday.h
>>
>> Should those prototypes be moved to include/vdso/gettime.h too and
>> eventually renamed, or are they considered too powerpc specific ?
> 
> I don't actually know, my initial interpretation was that
> these function names are part of the user ABI for the vdso,
> but I never looked closely enough at how vdso works to
> be sure what the actual ABI is.
> 
> If __c_kernel_clock_gettime() etc are not part of the user-facing
> ABI, I think renaming them for consistency with the other
> architectures would be best.
> 

User-facing ABI function is __kernel_clock_gettime(), defined in 
arch/powerpc/kernel/vdso/gettimeofday.S , see man vdso.
There is no prototype defined for it anywhere, obviously that's 
undetected because it is assembly. Should a prototype be added somewhere 
anyway ?

__kernel_clock_gettime() sets up a stack frame, retrieves the address of 
the datapage then calls __c_kernel_clock_gettime() which then calls 
__cvdso_clock_gettime_data() which is part of the generic CVDSO.

Maybe that's too different from what other architectures do ?

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

Re: [PATCH 15/22] arch: vdso: consolidate gettime prototypes

[Christophe Leroy]

Hi Arnd,

Le 08/11/2023 à 13:58, Arnd Bergmann a écrit :
> From: Arnd Bergmann 
> 
> The VDSO functions are defined as globals in the kernel sources but intended
> to be called from userspace, so there is no need to declare them in a kernel
> side header.
> 
> Without a prototype, this now causes warnings such as
> 
> arch/mips/vdso/vgettimeofday.c:14:5: error: no previous prototype for 
> '__vdso_clock_gettime' [-Werror=missing-prototypes]
> arch/mips/vdso/vgettimeofday.c:28:5: error: no previous prototype for 
> '__vdso_gettimeofday' [-Werror=missing-prototypes]
> arch/mips/vdso/vgettimeofday.c:36:5: error: no previous prototype for 
> '__vdso_clock_getres' [-Werror=missing-prototypes]
> arch/mips/vdso/vgettimeofday.c:42:5: error: no previous prototype for 
> '__vdso_clock_gettime64' [-Werror=missing-prototypes]
> arch/sparc/vdso/vclock_gettime.c:254:1: error: no previous prototype for 
> '__vdso_clock_gettime' [-Werror=missing-prototypes]
> arch/sparc/vdso/vclock_gettime.c:282:1: error: no previous prototype for 
> '__vdso_clock_gettime_stick' [-Werror=missing-prototypes]
> arch/sparc/vdso/vclock_gettime.c:307:1: error: no previous prototype for 
> '__vdso_gettimeofday' [-Werror=missing-prototypes]
> arch/sparc/vdso/vclock_gettime.c:343:1: error: no previous prototype for 
> '__vdso_gettimeofday_stick' [-Werror=missing-prototypes]
> 
> Most architectures have already added workarounds for these by adding
> declarations somewhere, but since these are all compatible, we should
> really just have one copy, with an #ifdef check for the 32-bit vs
> 64-bit variant and use that everywhere.
> 
> Unfortunately, the sparc version is currently incompatible since
> that never added support for __vdso_clock_gettime64() in 32-bit
> userland. For the moment, I'm leaving this one out, as I can't
> easily test it and it requires a larger rework.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>   arch/arm/include/asm/vdso.h  |  5 -
>   arch/arm/vdso/vgettimeofday.c|  1 +
>   arch/arm64/kernel/vdso32/vgettimeofday.c |  1 +
>   arch/csky/kernel/vdso/vgettimeofday.c| 11 +--
>   arch/loongarch/vdso/vgettimeofday.c  |  7 +--
>   arch/mips/vdso/vgettimeofday.c   |  1 +
>   arch/riscv/kernel/vdso/vgettimeofday.c   |  7 +--
>   arch/x86/entry/vdso/vclock_gettime.c | 10 +-
>   arch/x86/include/asm/vdso/gettimeofday.h |  2 --
>   arch/x86/um/vdso/um_vdso.c   |  1 +
>   include/vdso/gettime.h   | 23 +++
>   11 files changed, 31 insertions(+), 38 deletions(-)
>   create mode 100644 include/vdso/gettime.h

powerpc has functions doing more or less the same, they are called 
__c_kernel_clock_gettime() and alike with their prototypes siting in 
arch/powerpc/include/asm/vdso/gettimeofday.h

Should those prototypes be moved to include/vdso/gettime.h too and 
eventually renamed, or are they considered too powerpc specific ?

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

Re: [PATCH] treewide: drop CONFIG_EMBEDDED

[Christophe Leroy]

Hi,

Le 19/08/2023 à 05:33, Jesse T a écrit :
>>>
 Should there be a warning here to update change it instead of removal?
>>>
>>> kconfig doesn't have a warning mechanism AFAIK.
>>> Do you have an idea of how this would work?
> 
> No, unfortunately. As you said without a warning it would be overlooked so
> a change would not be necessary.
> 
> A possible solution is to check in a header file with:
> 
> #ifdef CONFIG_EMBEDDED
> #warning "CONFIG_EMBEDDED has changed to CONFIG_EXPERT"
> #endif
> 
> Does anyone else have an opinion on this?

My opinion is that has happen several times in the past and will happen 
again. It is not a big deal, whoever updates to a new kernel will make a 
savedefconfig and compare with previous defconfig and see what has 
changed. Once you see that CONFIG_EMBEDDED is disappearing you look at 
kernel history to find out why CONFIG_EMBEDDED disappears, and you 
understand from the commit message that you have to select CONFIG_EXPERT 
instead.

A couple examples I have in mind from the past:
- CONFIG_FORCE_MAX_ZONEORDER became CONFIG_ARCH_FORCE_MAX_ORDER
- CONFIG_MTD_NAND became CONFIG_MTD_RAW_NAND

> Since kconfig doesn't have a warning mechanism the patch seems fine as is.

So yes the patch is fine as is IMHO.

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

Re: [PATCH 16/17] [RFC] arch: turn -Wmissing-prototypes off conditionally

[Christophe Leroy]

Le 10/08/2023 à 16:19, Arnd Bergmann a écrit :
> From: Arnd Bergmann 
> 
> I have cleaned up the -Wmissing-prototypes warnings for most of the major 
> architectures
> as well as all drivers that get enabled for CONFIG_COMPILE_TEST, so now these 
> should be
> close to fixed on x86, arm, arm64, powerpc, s390, and riscv.
> 
> The other architectures tend to have a lot of these warning in architecture 
> specific
> code, primarily from functions that are only called from assembler code and do
> not otherwise need a declaration but still cause a warning without one. Other 
> cases
> are simply functions that should just be static or are missing an #include 
> statement.
> 
> In order to be able to turn the warning on globally by default without 
> breaking all
> these architectures, add a list of exceptions for architecture directories 
> that
> can revert back to the old behavior of not warning based on a new
> CONFIG_WNO_MISSING_PROTOTYPES option.

Some architectures only have a few of those errors/warnings.

For instance microblaze and parisc only have one each. Isn't it better 
to fix them rather then turn the errors off ?

Others like loongarch which is a recent actively maintained 
architecture, I'd expect the 30 errors to be easy to fix.

Many of the alpha ones seems to be brought by your commit e19d4ebc536d 
("alpha: add full ioread64/iowrite64 implementation")

Christophe

> 
> Signed-off-by: Arnd Bergmann 
> ---
> Below is the full list of warnings I see in defconfig builds for reference, 
> these
> do not need to be part of the changelog.
> 
> arch/alpha/include/asm/core_t2.h:465:20: error: no previous prototype for 
> 't2_readb' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:476:21: error: no previous prototype for 
> 't2_readw' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:491:21: error: no previous prototype for 
> 't2_readl' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:502:21: error: no previous prototype for 
> 't2_readq' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:515:22: error: no previous prototype for 
> 't2_writeb' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:526:22: error: no previous prototype for 
> 't2_writew' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:541:22: error: no previous prototype for 
> 't2_writel' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:550:22: error: no previous prototype for 
> 't2_writeq' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:562:31: error: no previous prototype for 
> 't2_ioportmap' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:567:31: error: no previous prototype for 
> 't2_ioremap' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:573:21: error: no previous prototype for 
> 't2_is_ioaddr' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:578:21: error: no previous prototype for 
> 't2_is_mmio' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:587:23: error: no previous prototype for 
> 't2_ioread16' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:587:23: error: no previous prototype for 
> 't2_ioread32' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:587:23: error: no previous prototype for 
> 't2_ioread64' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:587:23: error: no previous prototype for 
> 't2_ioread8' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:594:22: error: no previous prototype for 
> 't2_iowrite16' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:594:22: error: no previous prototype for 
> 't2_iowrite32' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:594:22: error: no previous prototype for 
> 't2_iowrite64' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:594:22: error: no previous prototype for 
> 't2_iowrite8' [-Werror=missing-prototypes]
> arch/alpha/include/asm/core_t2.h:614:33: error: no previous prototype for 
> 't2_iounmap' [-Werror=missing-prototypes]
> arch/alpha/include/asm/jensen.h:115:30: error: no previous prototype for 
> 'jensen_local_inb' [-Werror=missing-prototypes]
> arch/alpha/include/asm/jensen.h:120:22: error: no previous prototype for 
> 'jensen_local_outb' [-Werror=missing-prototypes]
> arch/alpha/include/asm/jensen.h:126:30: error: no previous prototype for 
> 'jensen_bus_inb' [-Werror=missing-prototypes]
> arch/alpha/include/asm/jensen.h:135:22: error: no previous prototype for 
> 'jensen_bus_outb' [-Werror=missing-prototypes]
> arch/alpha/include/asm/jensen.h:155:20: error: no previous prototype for 
> 'jensen_inb' [-Werror=missing-prototypes]
> arch/alpha/include/asm/jensen.h:163:22: error: no previous prototype for 
> 'jensen_outb' [-Werror=missing-prototypes]
> arch/alpha/include/asm/jensen.h:171:21: error: no previous prototype for 
> 'jensen_inw' [-Werror=missing-prototypes]
> 

Re: [PATCH 06/21] powerpc: dma-mapping: minimize for_cpu flushing

[Christophe Leroy]

Le 27/03/2023 à 14:13, Arnd Bergmann a écrit :
> From: Arnd Bergmann 
> 
> The powerpc dma_sync_*_for_cpu() variants do more flushes than on other
> architectures. Reduce it to what everyone else does:
> 
>   - No flush is needed after data has been sent to a device
> 
>   - When data has been received from a device, the cache only needs to
> be invalidated to clear out cache lines that were speculatively
> prefetched.
> 
> In particular, the second flushing of partial cache lines of bidirectional
> buffers is actively harmful -- if a single cache line is written by both
> the CPU and the device, flushing it again does not maintain coherency
> but instead overwrite the data that was just received from the device.

Hum . Who is right ?

That behaviour was introduced by commit 03d70617b8a7 ("powerpc: Prevent 
memory corruption due to cache invalidation of unaligned DMA buffer")

I think your commit log should explain why that commit was wrong, and 
maybe say that your patch is a revert of that commit ?

Christophe


> 
> Signed-off-by: Arnd Bergmann 
> ---
>   arch/powerpc/mm/dma-noncoherent.c | 18 --
>   1 file changed, 4 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/powerpc/mm/dma-noncoherent.c 
> b/arch/powerpc/mm/dma-noncoherent.c
> index f10869d27de5..e108cacf877f 100644
> --- a/arch/powerpc/mm/dma-noncoherent.c
> +++ b/arch/powerpc/mm/dma-noncoherent.c
> @@ -132,21 +132,11 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t 
> size,
>   switch (direction) {
>   case DMA_NONE:
>   BUG();
> - case DMA_FROM_DEVICE:
> - /*
> -  * invalidate only when cache-line aligned otherwise there is
> -  * the potential for discarding uncommitted data from the cache
> -  */
> - if ((start | end) & (L1_CACHE_BYTES - 1))
> - __dma_phys_op(start, end, DMA_CACHE_FLUSH);
> - else
> - __dma_phys_op(start, end, DMA_CACHE_INVAL);
> - break;
> - case DMA_TO_DEVICE: /* writeback only */
> - __dma_phys_op(start, end, DMA_CACHE_CLEAN);
> + case DMA_TO_DEVICE:
>   break;
> - case DMA_BIDIRECTIONAL: /* writeback and invalidate */
> - __dma_phys_op(start, end, DMA_CACHE_FLUSH);
> + case DMA_FROM_DEVICE:
> + case DMA_BIDIRECTIONAL:
> + __dma_phys_op(start, end, DMA_CACHE_INVAL);
>   break;
>   }
>   }
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v7 13/41] mm: Make pte_mkwrite() take a VMA

[Christophe Leroy]

Le 27/02/2023 à 23:29, Rick Edgecombe a écrit :
> The x86 Control-flow Enforcement Technology (CET) feature includes a new
> type of memory called shadow stack. This shadow stack memory has some
> unusual properties, which requires some core mm changes to function
> properly.
> 
> One of these unusual properties is that shadow stack memory is writable,
> but only in limited ways. These limits are applied via a specific PTE
> bit combination. Nevertheless, the memory is writable, and core mm code
> will need to apply the writable permissions in the typical paths that
> call pte_mkwrite().
> 
> In addition to VM_WRITE, the shadow stack VMA's will have a flag denoting
> that they are special shadow stack flavor of writable memory. So make
> pte_mkwrite() take a VMA, so that the x86 implementation of it can know to
> create regular writable memory or shadow stack memory.
> 
> Apply the same changes for pmd_mkwrite() and huge_pte_mkwrite().

I'm not sure it is a good idea to add a second argument to 
pte_mkwrite(). All pte_mk() only take a pte and nothing else.

I think you should do the same as commit d9ed9faac283 ("mm: add new 
arch_make_huge_pte() method for tile support")

Christophe

> 
> No functional change.
> 
> Cc: linux-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-al...@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-c...@vger.kernel.org
> Cc: linux-hexa...@vger.kernel.org
> Cc: linux-i...@vger.kernel.org
> Cc: loonga...@lists.linux.dev
> Cc: linux-m...@lists.linux-m68k.org
> Cc: Michal Simek 
> Cc: Dinh Nguyen 
> Cc: linux-m...@vger.kernel.org
> Cc: linux-openr...@vger.kernel.org
> Cc: linux-par...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-ri...@lists.infradead.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: sparcli...@vger.kernel.org
> Cc: linux...@lists.infradead.org
> Cc: xen-de...@lists.xenproject.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux...@kvack.org
> Tested-by: Pengfei Xu 
> Tested-by: John Allen 
> Tested-by: Kees Cook 
> Acked-by: Mike Rapoport (IBM) 
> Acked-by: Michael Ellerman 
> Acked-by: David Hildenbrand 
> Reviewed-by: Kees Cook 
> Suggested-by: David Hildenbrand 
> Signed-off-by: Rick Edgecombe 
> 
> ---
> Hi Non-x86 Arch’s,
> 
> x86 has a feature that allows for the creation of a special type of
> writable memory (shadow stack) that is only writable in limited specific
> ways. Previously, changes were proposed to core MM code to teach it to
> decide when to create normally writable memory or the special shadow stack
> writable memory, but David Hildenbrand suggested[0] to change
> pXX_mkwrite() to take a VMA, so awareness of shadow stack memory can be
> moved into x86 code.
> 
> Since pXX_mkwrite() is defined in every arch, it requires some tree-wide
> changes. So that is why you are seeing some patches out of a big x86
> series pop up in your arch mailing list. There is no functional change.
> After this refactor, the shadow stack series goes on to use the arch
> helpers to push shadow stack memory details inside arch/x86.
> 
> Testing was just 0-day build testing.
> 
> Hopefully that is enough context. Thanks!
> 
> [0] 
> https://lore.kernel.org/lkml/0e29a2d0-08d8-bcd6-ff26-4bea0e403...@redhat.com/#t
> 
> v6:
>   - New patch
> ---
>   Documentation/mm/arch_pgtable_helpers.rst|  9 ++---
>   arch/alpha/include/asm/pgtable.h |  6 +-
>   arch/arc/include/asm/hugepage.h  |  2 +-
>   arch/arc/include/asm/pgtable-bits-arcv2.h|  7 ++-
>   arch/arm/include/asm/pgtable-3level.h|  7 ++-
>   arch/arm/include/asm/pgtable.h   |  2 +-
>   arch/arm64/include/asm/pgtable.h |  4 ++--
>   arch/csky/include/asm/pgtable.h  |  2 +-
>   arch/hexagon/include/asm/pgtable.h   |  2 +-
>   arch/ia64/include/asm/pgtable.h  |  2 +-
>   arch/loongarch/include/asm/pgtable.h |  4 ++--
>   arch/m68k/include/asm/mcf_pgtable.h  |  2 +-
>   arch/m68k/include/asm/motorola_pgtable.h |  6 +-
>   arch/m68k/include/asm/sun3_pgtable.h |  6 +-
>   arch/microblaze/include/asm/pgtable.h|  2 +-
>   arch/mips/include/asm/pgtable.h  |  6 +++---
>   arch/nios2/include/asm/pgtable.h |  2 +-
>   arch/openrisc/include/asm/pgtable.h  |  2 +-
>   arch/parisc/include/asm/pgtable.h|  6 +-
>   arch/powerpc/include/asm/book3s/32/pgtable.h |  2 +-
>   arch/powerpc/include/asm/book3s/64/pgtable.h |  4 ++--
>   arch/powerpc/include/asm/nohash/32/pgtable.h |  2 +-
>   arch/powerpc/include/asm/nohash/32/pte-8xx.h |  2 +-
>   arch/powerpc/include/asm/nohash/64/pgtable.h |  2 +-
>   arch/riscv/include/asm/pgtable.h |  6 +++---
>   arch/s390/include/asm/hugetlb.h  |  4 ++--
>   arch/s390/include/asm/pgtable.h  |  4 ++--
>   arch/sh/include/asm/pgtable_32.h   

Re: [PATCH mm-unstable RFC 17/26] powerpc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on 32bit book3s

[Christophe Leroy]

Le 06/12/2022 à 15:47, David Hildenbrand a écrit :
> We already implemented support for 64bit book3s in commit bff9beaa2e80
> ("powerpc/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE for book3s")
> 
> Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE also in 32bit by reusing yet
> unused LSB 2 / MSB 29. There seems to be no real reason why that bit cannot
> be used, and reusing it avoids having to steal one bit from the swap
> offset.
> 
> While at it, mask the type in __swp_entry().
> 
> Cc: Michael Ellerman 
> Cc: Nicholas Piggin 
> Cc: Christophe Leroy 
> Signed-off-by: David Hildenbrand 
> ---
>   arch/powerpc/include/asm/book3s/32/pgtable.h | 38 +---
>   1 file changed, 33 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h 
> b/arch/powerpc/include/asm/book3s/32/pgtable.h
> index 75823f39e042..8107835b38c1 100644
> --- a/arch/powerpc/include/asm/book3s/32/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
> @@ -42,6 +42,9 @@
>   #define _PMD_PRESENT_MASK (PAGE_MASK)
>   #define _PMD_BAD(~PAGE_MASK)
>   
> +/* We borrow the _PAGE_USER bit to store the exclusive marker in swap PTEs. 
> */
> +#define _PAGE_SWP_EXCLUSIVE  _PAGE_USER
> +
>   /* And here we include common definitions */
>   
>   #define _PAGE_KERNEL_RO 0
> @@ -363,17 +366,42 @@ static inline void __ptep_set_access_flags(struct 
> vm_area_struct *vma,
>   #define pmd_page(pmd)   pfn_to_page(pmd_pfn(pmd))
>   
>   /*
> - * Encode and decode a swap entry.
> - * Note that the bits we use in a PTE for representing a swap entry
> - * must not include the _PAGE_PRESENT bit or the _PAGE_HASHPTE bit (if used).
> - *   -- paulus
> + * Encode/decode swap entries and swap PTEs. Swap PTEs are all PTEs that
> + * are !pte_none() && !pte_present().
> + *
> + * Format of swap PTEs (32bit PTEs):
> + *
> + * 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
> + *   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> + *   E H P <- type --> <- offset -->

That's in reversed order. _PAGE_HASHPTE is bit 30 and should be on the 
right hand side. Etc ...

Some exemple in arch/powerpc/include/asm/nohash/32/pte-40x.h or 
arch/powerpc/include/asm/nohash/32/pte-85xx.h

> + *
> + *   E is the exclusive marker that is not stored in swap entries.
> + *   _PAGE_PRESENT (P) and __PAGE_HASHPTE (H) must be 0.
> + *
> + * For 64bit PTEs, the offset is extended by 32bit.
>*/
>   #define __swp_type(entry)   ((entry).val & 0x1f)
>   #define __swp_offset(entry) ((entry).val >> 5)
> -#define __swp_entry(type, offset)((swp_entry_t) { (type) | ((offset) << 
> 5) })
> +#define __swp_entry(type, offset)((swp_entry_t) { ((type) & 0x1f) | 
> ((offset) << 5) })
>   #define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) 
> >> 3 })
>   #define __swp_entry_to_pte(x)   ((pte_t) { (x).val << 3 })
>   
> +#define __HAVE_ARCH_PTE_SWP_EXCLUSIVE
> +static inline int pte_swp_exclusive(pte_t pte)
> +{
> + return pte_val(pte) & _PAGE_SWP_EXCLUSIVE;
> +}
> +
> +static inline pte_t pte_swp_mkexclusive(pte_t pte)
> +{
> + return __pte(pte_val(pte) | _PAGE_SWP_EXCLUSIVE);
> +}
> +
> +static inline pte_t pte_swp_clear_exclusive(pte_t pte)
> +{
> + return __pte(pte_val(pte) & ~_PAGE_SWP_EXCLUSIVE);
> +}
> +
>   /* Generic accessors to PTE bits */
>   static inline int pte_write(pte_t pte)  { return 
> !!(pte_val(pte) & _PAGE_RW);}
>   static inline int pte_read(pte_t pte)   { return 1; }
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3 05/11] arc: mm: Convert to GENERIC_IOREMAP

[Christophe Leroy]

Le 09/10/2022 à 12:31, Baoquan He a écrit :
> By taking GENERIC_IOREMAP method, the generic ioremap_prot() and
> iounmap() are visible and available to arch. Arch only needs to
> provide implementation of arch_ioremap() or arch_iounmap() if there's
> arch specific handling needed in its ioremap() or iounmap(). This
> change will simplify implementation by removing duplicated codes with
> generic ioremap() and iounmap(), and has the equivalent functioality
> as before.
> 
> Here, add hooks arch_ioremap() and arch_iounmap() for arc's special
> operation when ioremap_prot() and iounmap(). Meanwhile define and
> implement arc's own ioremap() because arc has some special handling
> in ioremap() than standard ioremap().
> 
> Signed-off-by: Baoquan He 
> Cc: Vineet Gupta 
> Cc: linux-snps-arc@lists.infradead.org
> ---
>   arch/arc/Kconfig  |  1 +
>   arch/arc/include/asm/io.h | 19 +
>   arch/arc/mm/ioremap.c | 60 ++-
>   3 files changed, 23 insertions(+), 57 deletions(-)
> 
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 9e3653253ef2..a08d2abfaf61 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -26,6 +26,7 @@ config ARC
>   select GENERIC_PENDING_IRQ if SMP
>   select GENERIC_SCHED_CLOCK
>   select GENERIC_SMP_IDLE_THREAD
> + select GENERIC_IOREMAP
>   select HAVE_ARCH_KGDB
>   select HAVE_ARCH_TRACEHOOK
>   select HAVE_ARCH_TRANSPARENT_HUGEPAGE if ARC_MMU_V4
> diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
> index 8f777d6441a5..41a317567920 100644
> --- a/arch/arc/include/asm/io.h
> +++ b/arch/arc/include/asm/io.h
> @@ -20,9 +20,20 @@
>   #define __iowmb()   do { } while (0)
>   #endif
>   
> -extern void __iomem *ioremap(phys_addr_t paddr, unsigned long size);
> -extern void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long size,
> -   unsigned long flags);
> +/*
> + * I/O memory mapping functions.
> + */
> +
> +void __iomem *
> +arch_ioremap(phys_addr_t *paddr, size_t size, unsigned long *prot_val);
> +#define arch_ioremap arch_ioremap
> +
> +bool arch_iounmap(void __iomem *addr);
> +#define arch_iounmap arch_iounmap
> +
> +void __iomem *ioremap(phys_addr_t paddr, unsigned long size);
> +#define ioremap ioremap
> +
>   static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
>   {
>   return (void __iomem *)port;
> @@ -32,8 +43,6 @@ static inline void ioport_unmap(void __iomem *addr)
>   {
>   }
>   
> -extern void iounmap(const void __iomem *addr);
> -
>   /*
>* io{read,write}{16,32}be() macros
>*/
> diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
> index 0ee75aca6e10..c2dcacd56aca 100644
> --- a/arch/arc/mm/ioremap.c
> +++ b/arch/arc/mm/ioremap.c
> @@ -25,13 +25,6 @@ static inline bool arc_uncached_addr_space(phys_addr_t 
> paddr)
>   
>   void __iomem *ioremap(phys_addr_t paddr, unsigned long size)
>   {
> - phys_addr_t end;
> -
> - /* Don't allow wraparound or zero size */
> - end = paddr + size - 1;
> - if (!size || (end < paddr))
> - return NULL;
> -
>   /*
>* If the region is h/w uncached, MMU mapping can be elided as optim
>* The cast to u32 is fine as this region can only be inside 4GB
> @@ -44,62 +37,25 @@ void __iomem *ioremap(phys_addr_t paddr, unsigned long 
> size)
>   }
>   EXPORT_SYMBOL(ioremap);
>   
> -/*
> - * ioremap with access flags
> - * Cache semantics wise it is same as ioremap - "forced" uncached.
> - * However unlike vanilla ioremap which bypasses ARC MMU for addresses in
> - * ARC hardware uncached region, this one still goes thru the MMU as caller
> - * might need finer access control (R/W/X)
> - */
> -void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long size,
> -unsigned long flags)
> +void __iomem *
> +arch_ioremap(phys_addr_t *paddr, size_t size, unsigned long *prot_val)
>   {
> - unsigned int off;
> - unsigned long vaddr;
> - struct vm_struct *area;
> - phys_addr_t end;
> - pgprot_t prot = __pgprot(flags);
> -
> - /* Don't allow wraparound, zero size */
> - end = paddr + size - 1;
> - if ((!size) || (end < paddr))
> - return NULL;
> -
>   /* An early platform driver might end up here */
>   if (!slab_is_available())
> - return NULL;
> + return IOMEM_ERR_PTR(-EINVAL);

I think the slab_is_available() check should be done in the generic 
functions. On all architectures SLAB must be available before you can 
use get_vm_area_caller() and vunmap()

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

[RFC PATCH 5/8] arc: mm: Convert to GENERIC_IOREMAP

[Christophe Leroy]

From: Baoquan He 

By taking GENERIC_IOREMAP method, the generic ioremap_prot() and
iounmap() are visible and available to arch. Arch only needs to
provide implementation of arch_ioremap() or arch_iounmap() if there's
arch specific handling needed in its ioremap() or iounmap(). This
change will simplify implementation by removing duplicated codes with
generic ioremap() and iounmap(), and has the equivalent functioality
as before.

Here, add hooks arch_ioremap() and arch_iounmap() for arc's special
operation when ioremap_prot() and iounmap(). Meanwhile define and
implement arc's own ioremap() because arc has some special handling
in ioremap() than standard ioremap().

Signed-off-by: Baoquan He 
Cc: Vineet Gupta 
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Christophe Leroy 
---
 arch/arc/Kconfig  |  1 +
 arch/arc/include/asm/io.h |  7 +++---
 arch/arc/mm/ioremap.c | 46 +++
 3 files changed, 8 insertions(+), 46 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 9e3653253ef2..a08d2abfaf61 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -26,6 +26,7 @@ config ARC
select GENERIC_PENDING_IRQ if SMP
select GENERIC_SCHED_CLOCK
select GENERIC_SMP_IDLE_THREAD
+   select GENERIC_IOREMAP
select HAVE_ARCH_KGDB
select HAVE_ARCH_TRACEHOOK
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if ARC_MMU_V4
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 8f777d6441a5..53b0f1e4f276 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -21,8 +21,8 @@
 #endif
 
 extern void __iomem *ioremap(phys_addr_t paddr, unsigned long size);
-extern void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long size,
- unsigned long flags);
+#define ioremap ioremap
+#define ioremap_prot ioremap_prot
 static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
 {
return (void __iomem *)port;
@@ -32,7 +32,8 @@ static inline void ioport_unmap(void __iomem *addr)
 {
 }
 
-extern void iounmap(const void __iomem *addr);
+bool iounmap_allowed(void *addr);
+#define iounmap_allowed iounmap_allowed
 
 /*
  * io{read,write}{16,32}be() macros
diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
index 0ee75aca6e10..02b750abccee 100644
--- a/arch/arc/mm/ioremap.c
+++ b/arch/arc/mm/ioremap.c
@@ -25,13 +25,6 @@ static inline bool arc_uncached_addr_space(phys_addr_t paddr)
 
 void __iomem *ioremap(phys_addr_t paddr, unsigned long size)
 {
-   phys_addr_t end;
-
-   /* Don't allow wraparound or zero size */
-   end = paddr + size - 1;
-   if (!size || (end < paddr))
-   return NULL;
-
/*
 * If the region is h/w uncached, MMU mapping can be elided as optim
 * The cast to u32 is fine as this region can only be inside 4GB
@@ -54,52 +47,19 @@ EXPORT_SYMBOL(ioremap);
 void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long size,
   unsigned long flags)
 {
-   unsigned int off;
-   unsigned long vaddr;
-   struct vm_struct *area;
-   phys_addr_t end;
pgprot_t prot = __pgprot(flags);
 
-   /* Don't allow wraparound, zero size */
-   end = paddr + size - 1;
-   if ((!size) || (end < paddr))
-   return NULL;
-
/* An early platform driver might end up here */
if (!slab_is_available())
return NULL;
 
/* force uncached */
-   prot = pgprot_noncached(prot);
-
-   /* Mappings have to be page-aligned */
-   off = paddr & ~PAGE_MASK;
-   paddr &= PAGE_MASK_PHYS;
-   size = PAGE_ALIGN(end + 1) - paddr;
-
-   /*
-* Ok, go for it..
-*/
-   area = get_vm_area(size, VM_IOREMAP);
-   if (!area)
-   return NULL;
-   area->phys_addr = paddr;
-   vaddr = (unsigned long)area->addr;
-   if (ioremap_page_range(vaddr, vaddr + size, paddr, prot)) {
-   vunmap((void __force *)vaddr);
-   return NULL;
-   }
-   return (void __iomem *)(off + (char __iomem *)vaddr);
+   return generic_ioremap_prot(paddr, size, pgprot_noncached(prot));
 }
 EXPORT_SYMBOL(ioremap_prot);
 
-
-void iounmap(const void __iomem *addr)
+bool iounmap_allowed(void *addr)
 {
/* weird double cast to handle phys_addr_t > 32 bits */
-   if (arc_uncached_addr_space((phys_addr_t)(u32)addr))
-   return;
-
-   vfree((void *)(PAGE_MASK & (unsigned long __force)addr));
+   return !arc_uncached_addr_space((phys_addr_t)(u32)addr);
 }
-EXPORT_SYMBOL(iounmap);
-- 
2.37.1


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

Re: [PATCH V6 00/26] mm/mmap: Drop __SXXX/__PXXX macros from across platforms

[Christophe Leroy]

Le 06/07/2022 à 07:57, Anshuman Khandual a écrit :
> 
> 
> On 6/30/22 10:46, Anshuman Khandual wrote:
>> __SXXX/__PXXX macros is an unnecessary abstraction layer in creating the
>> generic protection_map[] array which is used for vm_get_page_prot(). This
>> abstraction layer can be avoided, if the platforms just define the array
>> protection_map[] for all possible vm_flags access permission combinations
>> and also export vm_get_page_prot() implementation.
>>
>> This series drops __SXXX/__PXXX macros from across platforms in the tree.
>> First it build protects generic protection_map[] array with '#ifdef __P000'
>> and moves it inside platforms which enable ARCH_HAS_VM_GET_PAGE_PROT. Later
>> this build protects same array with '#ifdef ARCH_HAS_VM_GET_PAGE_PROT' and
>> moves inside remaining platforms while enabling ARCH_HAS_VM_GET_PAGE_PROT.
>> This adds a new macro DECLARE_VM_GET_PAGE_PROT defining the current generic
>> vm_get_page_prot(), in order for it to be reused on platforms that do not
>> require custom implementation. Finally, ARCH_HAS_VM_GET_PAGE_PROT can just
>> be dropped, as all platforms now define and export vm_get_page_prot(), via
>> looking up a private and static protection_map[] array. protection_map[]
>> data type has been changed as 'static const' on all platforms that do not
>> change it during boot.
>>
>> This series applies on v5.19-rc4 and has been build tested for multiple
>> platforms. While here it has dropped off all previous tags from folks after
>> the current restructuring. Series common CC list has been expanded to cover
>> all impacted platforms for wider reach.
>>
>> - Anshuman
>>
>> Changes in V6:
>>
>> - Converted protection_map[] array as 'static const' on sparc32 platform
>> - Rebased on v5.19-rc4
>> - Collected tags
> 
> There are two linux-next based build fixes for this series (listed below), 
> when
> vm_get_page_prot() gets redefined with !CONFIG_MMU. Platform 
> vm_get_page_prot()
> is required only with CONFIG_MMU enabled, otherwise there is a generic 
> fallback
> stub in include/linux/mm.h
> 
> https://lore.kernel.org/all/20220705221411.3381797-1-jcmvb...@gmail.com/  
> [xtensa]
> https://lore.kernel.org/all/20220706054002.1936820-1-anshuman.khand...@arm.com/
>  [sh]
> 
> It does not seem CONFIG_MMU can be disabled on other platforms thus exposing 
> a build
> failure. But just to be on the safer side, should all vm_get_page_prot() be 
> wrapped
> around with #ifdef CONFIG_MMU ? In that case will resend the series with 
> above build
> fixes folded back in as well. Please do suggest. Thank you.
> 

As far as I can see in Kconfig, CONFIG_MMU is user selectable on the 
following architectures:
- ARM
- M68K
- RISCV
- SH

And is disabled by default on XTENSA.

So I guess ARM, M68K, RISCV, SH and XTENSA should have it wrapped around 
#ifdef CONFIG_MMU , or have it in a file that is not built when 
CONFIG_MMU is not set.

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

Re: [PATCH V5 26/26] mm/mmap: Drop ARCH_HAS_VM_GET_PAGE_PROT

[Christophe Leroy]

Le 27/06/2022 à 06:58, Anshuman Khandual a écrit :
> Now all the platforms enable ARCH_HAS_GET_PAGE_PROT. They define and export
> own vm_get_page_prot() whether custom or standard DECLARE_VM_GET_PAGE_PROT.
> Hence there is no need for default generic fallback for vm_get_page_prot().
> Just drop this fallback and also ARCH_HAS_GET_PAGE_PROT mechanism.
> 
> Cc: Andrew Morton 
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Reviewed-by: Christoph Hellwig 
> Signed-off-by: Anshuman Khandual 

Reviewed-by: Christophe Leroy 

> ---
>   arch/alpha/Kconfig  |  1 -
>   arch/arc/Kconfig|  1 -
>   arch/arm/Kconfig|  1 -
>   arch/arm64/Kconfig  |  1 -
>   arch/csky/Kconfig   |  1 -
>   arch/hexagon/Kconfig|  1 -
>   arch/ia64/Kconfig   |  1 -
>   arch/loongarch/Kconfig  |  1 -
>   arch/m68k/Kconfig   |  1 -
>   arch/microblaze/Kconfig |  1 -
>   arch/mips/Kconfig   |  1 -
>   arch/nios2/Kconfig  |  1 -
>   arch/openrisc/Kconfig   |  1 -
>   arch/parisc/Kconfig |  1 -
>   arch/powerpc/Kconfig|  1 -
>   arch/riscv/Kconfig  |  1 -
>   arch/s390/Kconfig   |  1 -
>   arch/sh/Kconfig |  1 -
>   arch/sparc/Kconfig  |  1 -
>   arch/um/Kconfig |  1 -
>   arch/x86/Kconfig|  1 -
>   arch/xtensa/Kconfig |  1 -
>   include/linux/mm.h  |  3 ---
>   mm/Kconfig  |  3 ---
>   mm/mmap.c   | 22 --
>   25 files changed, 50 deletions(-)
> 
> diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
> index db1c8b329461..7d0d26b5b3f5 100644
> --- a/arch/alpha/Kconfig
> +++ b/arch/alpha/Kconfig
> @@ -2,7 +2,6 @@
>   config ALPHA
>   bool
>   default y
> - select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_32BIT_USTAT_F_TINODE
>   select ARCH_MIGHT_HAVE_PC_PARPORT
>   select ARCH_MIGHT_HAVE_PC_SERIO
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 8be56a5d8a9b..9e3653253ef2 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -13,7 +13,6 @@ config ARC
>   select ARCH_HAS_SETUP_DMA_OPS
>   select ARCH_HAS_SYNC_DMA_FOR_CPU
>   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> - select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_SUPPORTS_ATOMIC_RMW if ARC_HAS_LLSC
>   select ARCH_32BIT_OFF_T
>   select BUILDTIME_TABLE_SORT
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index e153b6d4fc5b..7630ba9cb6cc 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -24,7 +24,6 @@ config ARM
>   select ARCH_HAS_SYNC_DMA_FOR_CPU if SWIOTLB || !MMU
>   select ARCH_HAS_TEARDOWN_DMA_OPS if MMU
>   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> - select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_HAVE_CUSTOM_GPIO_H
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG if CPU_V7 || CPU_V7M || CPU_V6K
>   select ARCH_HAS_GCOV_PROFILE_ALL
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 1652a9800ebe..7030bf3f8d6f 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -45,7 +45,6 @@ config ARM64
>   select ARCH_HAS_SYSCALL_WRAPPER
>   select ARCH_HAS_TEARDOWN_DMA_OPS if IOMMU_SUPPORT
>   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> - select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_HAS_ZONE_DMA_SET if EXPERT
>   select ARCH_HAVE_ELF_PROT
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG
> diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
> index 588b8a9c68ed..21d72b078eef 100644
> --- a/arch/csky/Kconfig
> +++ b/arch/csky/Kconfig
> @@ -6,7 +6,6 @@ config CSKY
>   select ARCH_HAS_GCOV_PROFILE_ALL
>   select ARCH_HAS_SYNC_DMA_FOR_CPU
>   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> - select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_USE_BUILTIN_BSWAP
>   select ARCH_USE_QUEUED_RWLOCKS
>   select ARCH_WANT_FRAME_POINTERS if !CPU_CK610 && 
> $(cc-option,-mbacktrace)
> diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
> index bc4ceecd0588..54eadf265178 100644
> --- a/arch/hexagon/Kconfig
> +++ b/arch/hexagon/Kconfig
> @@ -6,7 +6,6 @@ config HEXAGON
>   def_bool y
>   select ARCH_32BIT_OFF_T
>   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> - select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_NO_PREEMPT
>   select DMA_GLOBAL_POOL
>   # Other pending projects/to-do items.
> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> index 0510a5737711..cb93769a9f2a 100644
> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -12,7 +12,6 @@ config IA64
>   select ARCH_HAS_DMA_MARK_CLEAN
>   select ARCH_HAS_STRNCPY_FROM_USER
>   select ARCH_HAS_STRNLEN

Re: [PATCH V5 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT

[Christophe Leroy]

Le 27/06/2022 à 06:58, Anshuman Khandual a écrit :
> Now that protection_map[] has been moved inside those platforms that enable
> 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 
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 

Reviewed-by: Christophe Leroy 

> ---
>   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 47bfe038d46e..65b7f3d9ff87 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];
>   #endif
>   
> diff --git a/mm/mmap.c b/mm/mmap.c
> index b46d5e931bb3..2cc722e162fa 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -81,7 +81,7 @@ static void unmap_region(struct mm_struct *mm,
>   struct vm_area_struct *vma, struct vm_area_struct *prev,
>   unsigned long start, unsigned long end);
>   
> -#ifdef __P000
> +#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
>   pgprot_t protection_map[16] __ro_after_init = {
>   [VM_NONE]   = __P000,
>   [VM_READ]   = __P001,
> @@ -100,9 +100,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

Re: [PATCH V5 03/26] powerpc/mm: Move protection_map[] inside the platform

[Christophe Leroy]

Le 27/06/2022 à 06:58, Anshuman Khandual a écrit :
> This moves protection_map[] inside the platform and while here, also enable
> ARCH_HAS_VM_GET_PAGE_PROT on 32 bit and nohash 64 (aka book3e/64) platforms
> via DECLARE_VM_GET_PAGE_PROT.
> 
> Cc: Michael Ellerman 
> Cc: Paul Mackerras 
> Cc: Nicholas Piggin 
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 

Reviewed-by: Christophe Leroy 

> ---
>   arch/powerpc/Kconfig   |  2 +-
>   arch/powerpc/include/asm/pgtable.h | 20 +---
>   arch/powerpc/mm/pgtable.c  | 24 
>   3 files changed, 26 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index c2ce2e60c8f0..1035d172c7dd 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -140,7 +140,7 @@ config PPC
>   select ARCH_HAS_TICK_BROADCAST  if GENERIC_CLOCKEVENTS_BROADCAST
>   select ARCH_HAS_UACCESS_FLUSHCACHE
>   select ARCH_HAS_UBSAN_SANITIZE_ALL
> - select ARCH_HAS_VM_GET_PAGE_PROTif PPC_BOOK3S_64
> + select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG
>   select ARCH_KEEP_MEMBLOCK
>   select ARCH_MIGHT_HAVE_PC_PARPORT
> diff --git a/arch/powerpc/include/asm/pgtable.h 
> b/arch/powerpc/include/asm/pgtable.h
> index d564d0ecd4cd..33f4bf8d22b0 100644
> --- a/arch/powerpc/include/asm/pgtable.h
> +++ b/arch/powerpc/include/asm/pgtable.h
> @@ -20,25 +20,6 @@ struct mm_struct;
>   #include 
>   #endif /* !CONFIG_PPC_BOOK3S */
>   
> -/* Note due to the way vm flags are laid out, the bits are XWR */
> -#define __P000   PAGE_NONE
> -#define __P001   PAGE_READONLY
> -#define __P010   PAGE_COPY
> -#define __P011   PAGE_COPY
> -#define __P100   PAGE_READONLY_X
> -#define __P101   PAGE_READONLY_X
> -#define __P110   PAGE_COPY_X
> -#define __P111   PAGE_COPY_X
> -
> -#define __S000   PAGE_NONE
> -#define __S001   PAGE_READONLY
> -#define __S010   PAGE_SHARED
> -#define __S011   PAGE_SHARED
> -#define __S100   PAGE_READONLY_X
> -#define __S101   PAGE_READONLY_X
> -#define __S110   PAGE_SHARED_X
> -#define __S111   PAGE_SHARED_X
> -
>   #ifndef __ASSEMBLY__
>   
>   #ifndef MAX_PTRS_PER_PGD
> @@ -79,6 +60,7 @@ extern void paging_init(void);
>   void poking_init(void);
>   
>   extern unsigned long ioremap_bot;
> +extern const pgprot_t protection_map[16];
>   
>   /*
>* kern_addr_valid is intended to indicate whether an address is a valid
> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
> index e6166b71d36d..cb2dcdb18f8e 100644
> --- a/arch/powerpc/mm/pgtable.c
> +++ b/arch/powerpc/mm/pgtable.c
> @@ -472,3 +472,27 @@ pte_t *__find_linux_pte(pgd_t *pgdir, unsigned long ea,
>   return ret_pte;
>   }
>   EXPORT_SYMBOL_GPL(__find_linux_pte);
> +
> +/* Note due to the way vm flags are laid out, the bits are XWR */
> +const pgprot_t protection_map[16] = {
> + [VM_NONE]   = PAGE_NONE,
> + [VM_READ]   = PAGE_READONLY,
> + [VM_WRITE]  = PAGE_COPY,
> + [VM_WRITE | VM_READ]= PAGE_COPY,
> + [VM_EXEC]   = PAGE_READONLY_X,
> + [VM_EXEC | VM_READ] = PAGE_READONLY_X,
> + [VM_EXEC | VM_WRITE]= PAGE_COPY_X,
> + [VM_EXEC | VM_WRITE | VM_READ]  = PAGE_COPY_X,
> + [VM_SHARED] = PAGE_NONE,
> + [VM_SHARED | VM_READ]   = PAGE_READONLY,
> + [VM_SHARED | VM_WRITE]  = PAGE_SHARED,
> + [VM_SHARED | VM_WRITE | VM_READ]= PAGE_SHARED,
> + [VM_SHARED | VM_EXEC]   = PAGE_READONLY_X,
> + [VM_SHARED | VM_EXEC | VM_READ] = PAGE_READONLY_X,
> + [VM_SHARED | VM_EXEC | VM_WRITE]= PAGE_SHARED_X,
> + [VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]  = PAGE_SHARED_X
> +};
> +
> +#ifndef CONFIG_PPC_BOOK3S_64
> +DECLARE_VM_GET_PAGE_PROT
> +#endif
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V5 02/26] mm/mmap: Define DECLARE_VM_GET_PAGE_PROT

[Christophe Leroy]

Le 27/06/2022 à 06:58, Anshuman Khandual a écrit :
> This just converts the generic vm_get_page_prot() implementation into a new
> macro i.e DECLARE_VM_GET_PAGE_PROT which later can be used across platforms
> when enabling them with ARCH_HAS_VM_GET_PAGE_PROT. This does not create any
> functional change.
> 
> Cc: Andrew Morton 
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Suggested-by: Christoph Hellwig 
> Signed-off-by: Anshuman Khandual 

Reviewed-by: Christophe Leroy 

> ---
>   include/linux/pgtable.h | 28 
>   mm/mmap.c   | 26 +-
>   2 files changed, 29 insertions(+), 25 deletions(-)
> 
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 3cdc16cfd867..014ee8f0fbaa 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -1689,4 +1689,32 @@ typedef unsigned int pgtbl_mod_mask;
>   #define MAX_PTRS_PER_P4D PTRS_PER_P4D
>   #endif
>   
> +/* description of effects of mapping type and prot in current implementation.
> + * this is due to the limited x86 page protection hardware.  The expected
> + * behavior is in parens:
> + *
> + * map_type  prot
> + *   PROT_NONE   PROT_READ   PROT_WRITE  PROT_EXEC
> + * MAP_SHAREDr: (no) no  r: (yes) yesr: (no) yes r: (no) 
> yes
> + *   w: (no) no  w: (no) no  w: (yes) yesw: (no) no
> + *   x: (no) no  x: (no) yes x: (no) yes x: (yes) yes
> + *
> + * MAP_PRIVATE   r: (no) no  r: (yes) yesr: (no) yes r: (no) 
> yes
> + *   w: (no) no  w: (no) no  w: (copy) copy  w: (no) no
> + *   x: (no) no  x: (no) yes x: (no) yes x: (yes) yes
> + *
> + * On arm64, PROT_EXEC has the following behaviour for both MAP_SHARED and
> + * MAP_PRIVATE (with Enhanced PAN supported):
> + *   r: (no) no
> + *   w: (no) no
> + *   x: (yes) yes
> + */
> +#define DECLARE_VM_GET_PAGE_PROT \
> +pgprot_t vm_get_page_prot(unsigned long vm_flags)\
> +{\
> + return protection_map[vm_flags &\
> + (VM_READ | VM_WRITE | VM_EXEC | VM_SHARED)];\
> +}\
> +EXPORT_SYMBOL(vm_get_page_prot);
> +
>   #endif /* _LINUX_PGTABLE_H */
> diff --git a/mm/mmap.c b/mm/mmap.c
> index b01f0280bda2..b46d5e931bb3 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -81,26 +81,6 @@ static void unmap_region(struct mm_struct *mm,
>   struct vm_area_struct *vma, struct vm_area_struct *prev,
>   unsigned long start, unsigned long end);
>   
> -/* description of effects of mapping type and prot in current implementation.
> - * this is due to the limited x86 page protection hardware.  The expected
> - * behavior is in parens:
> - *
> - * map_type  prot
> - *   PROT_NONE   PROT_READ   PROT_WRITE  PROT_EXEC
> - * MAP_SHAREDr: (no) no  r: (yes) yesr: (no) yes r: (no) 
> yes
> - *   w: (no) no  w: (no) no  w: (yes) yesw: (no) no
> - *   x: (no) no  x: (no) yes x: (no) yes x: (yes) yes
> - *
> - * MAP_PRIVATE   r: (no) no  r: (yes) yesr: (no) yes r: (no) 
> yes
> - *   w: (no) no  w: (no) no  w: (copy) copy  w: (no) no
> - *   x: (no) no  x: (no) yes x: (no) yes x: (yes) yes
> - *
> - * On arm64, PROT_EXEC has the following behaviour for both MAP_SHARED and
> - * MAP_PRIVATE (with Enhanced PAN supported):
> - *   r: (no) no
> - *   w: (no) no
> - *   x: (yes) yes
> - */
>   #ifdef __P000
>   pgprot_t protection_map[16] __ro_after_init = {
>   [VM_NONE]   = __P000,
> @@ -123,11 +103,7 @@ pgprot_t protection_map[16] __ro_after_init = {
>   #endif
>   
>   #ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
> -pgprot_t vm_get_page_prot(unsigned long vm_flags)
> -{
> - return protection_map[vm_flags & (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)];
> -}
> -EXPORT_SYMBOL(vm_get_page_prot);
> +DECLARE_VM_GET_PAGE_PROT
>   #endif  /* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
>   
>   static pgprot_t vm_pgprot_modify(pgprot_t oldprot, unsigned long vm_flags)
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V5 01/26] mm/mmap: Build protect protection_map[] with __P000

[Christophe Leroy]

Le 27/06/2022 à 06:58, Anshuman Khandual a écrit :
> Build protect generic protection_map[] array with __P000, so that it can be
> moved inside all the platforms one after the other. Otherwise there will be
> build failures during this process. CONFIG_ARCH_HAS_VM_GET_PAGE_PROT cannot
> be used for this purpose as only certain platforms enable this config now.
> 
> Cc: Andrew Morton 
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Reviewed-by: Christoph Hellwig 
> Suggested-by: Christophe Leroy 
> Signed-off-by: Anshuman Khandual 

Reviewed-by: Christophe Leroy 

> ---
>   include/linux/mm.h | 2 ++
>   mm/mmap.c  | 2 ++
>   2 files changed, 4 insertions(+)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index bc8f326be0ce..47bfe038d46e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -424,7 +424,9 @@ 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
>   extern pgprot_t protection_map[16];
> +#endif
>   
>   /*
>* The default fault flags that should be used by most of the
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 61e6135c54ef..b01f0280bda2 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -101,6 +101,7 @@ static void unmap_region(struct mm_struct *mm,
>*  w: (no) no
>*  x: (yes) yes
>*/
> +#ifdef __P000
>   pgprot_t protection_map[16] __ro_after_init = {
>   [VM_NONE]   = __P000,
>   [VM_READ]   = __P001,
> @@ -119,6 +120,7 @@ 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
>   pgprot_t vm_get_page_prot(unsigned long vm_flags)
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V4 26/26] mm/mmap: Drop ARCH_HAS_VM_GET_PAGE_PROT

[Christophe Leroy]

Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
> Now all the platforms enable ARCH_HAS_GET_PAGE_PROT. They define and export
> own vm_get_page_prot() whether custom or standard DECLARE_VM_GET_PAGE_PROT.
> Hence there is no need for default generic fallback for vm_get_page_prot().
> Just drop this fallback and also ARCH_HAS_GET_PAGE_PROT mechanism.
> 
> Cc: Andrew Morton 
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 

Reviewed-by: Christophe Leroy 

> ---
>   arch/alpha/Kconfig  |  1 -
>   arch/arc/Kconfig|  1 -
>   arch/arm/Kconfig|  1 -
>   arch/arm64/Kconfig  |  1 -
>   arch/csky/Kconfig   |  1 -
>   arch/hexagon/Kconfig|  1 -
>   arch/ia64/Kconfig   |  1 -
>   arch/loongarch/Kconfig  |  1 -
>   arch/m68k/Kconfig   |  1 -
>   arch/microblaze/Kconfig |  1 -
>   arch/mips/Kconfig   |  1 -
>   arch/nios2/Kconfig  |  1 -
>   arch/openrisc/Kconfig   |  1 -
>   arch/parisc/Kconfig |  1 -
>   arch/powerpc/Kconfig|  1 -
>   arch/riscv/Kconfig  |  1 -
>   arch/s390/Kconfig   |  1 -
>   arch/sh/Kconfig |  1 -
>   arch/sparc/Kconfig  |  1 -
>   arch/um/Kconfig |  1 -
>   arch/x86/Kconfig|  1 -
>   arch/xtensa/Kconfig |  1 -
>   include/linux/mm.h  |  3 ---
>   mm/Kconfig  |  3 ---
>   mm/mmap.c   | 22 --
>   25 files changed, 50 deletions(-)
> 
> diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
> index db1c8b329461..7d0d26b5b3f5 100644
> --- a/arch/alpha/Kconfig
> +++ b/arch/alpha/Kconfig
> @@ -2,7 +2,6 @@
>   config ALPHA
>   bool
>   default y
> - select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_32BIT_USTAT_F_TINODE
>   select ARCH_MIGHT_HAVE_PC_PARPORT
>   select ARCH_MIGHT_HAVE_PC_SERIO
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 8be56a5d8a9b..9e3653253ef2 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -13,7 +13,6 @@ config ARC
>   select ARCH_HAS_SETUP_DMA_OPS
>   select ARCH_HAS_SYNC_DMA_FOR_CPU
>   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> - select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_SUPPORTS_ATOMIC_RMW if ARC_HAS_LLSC
>   select ARCH_32BIT_OFF_T
>   select BUILDTIME_TABLE_SORT
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index e153b6d4fc5b..7630ba9cb6cc 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -24,7 +24,6 @@ config ARM
>   select ARCH_HAS_SYNC_DMA_FOR_CPU if SWIOTLB || !MMU
>   select ARCH_HAS_TEARDOWN_DMA_OPS if MMU
>   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> - select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_HAVE_CUSTOM_GPIO_H
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG if CPU_V7 || CPU_V7M || CPU_V6K
>   select ARCH_HAS_GCOV_PROFILE_ALL
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 1652a9800ebe..7030bf3f8d6f 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -45,7 +45,6 @@ config ARM64
>   select ARCH_HAS_SYSCALL_WRAPPER
>   select ARCH_HAS_TEARDOWN_DMA_OPS if IOMMU_SUPPORT
>   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> - select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_HAS_ZONE_DMA_SET if EXPERT
>   select ARCH_HAVE_ELF_PROT
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG
> diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
> index 588b8a9c68ed..21d72b078eef 100644
> --- a/arch/csky/Kconfig
> +++ b/arch/csky/Kconfig
> @@ -6,7 +6,6 @@ config CSKY
>   select ARCH_HAS_GCOV_PROFILE_ALL
>   select ARCH_HAS_SYNC_DMA_FOR_CPU
>   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> - select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_USE_BUILTIN_BSWAP
>   select ARCH_USE_QUEUED_RWLOCKS
>   select ARCH_WANT_FRAME_POINTERS if !CPU_CK610 && 
> $(cc-option,-mbacktrace)
> diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
> index bc4ceecd0588..54eadf265178 100644
> --- a/arch/hexagon/Kconfig
> +++ b/arch/hexagon/Kconfig
> @@ -6,7 +6,6 @@ config HEXAGON
>   def_bool y
>   select ARCH_32BIT_OFF_T
>   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> - select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_NO_PREEMPT
>   select DMA_GLOBAL_POOL
>   # Other pending projects/to-do items.
> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> index 0510a5737711..cb93769a9f2a 100644
> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -12,7 +12,6 @@ config IA64
>   select ARCH_HAS_DMA_MARK_CLEAN
>   select ARCH_HAS_STRNCPY_FROM_USER
>   select ARCH_HAS_STRNLEN_USER
> - select ARCH_HA

Re: [PATCH V4 02/26] mm/mmap: Define DECLARE_VM_GET_PAGE_PROT

[Christophe Leroy]

Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
> This just converts the generic vm_get_page_prot() implementation into a new
> macro i.e DECLARE_VM_GET_PAGE_PROT which later can be used across platforms
> when enabling them with ARCH_HAS_VM_GET_PAGE_PROT. This does not create any
> functional change.
> 
> Cc: Andrew Morton 
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Suggested-by: Christoph Hellwig 
> Signed-off-by: Anshuman Khandual 

Reviewed-by: Christophe Leroy 

> ---
>   include/linux/mm.h | 8 
>   mm/mmap.c  | 6 +-
>   2 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 47bfe038d46e..237828c2bae2 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -428,6 +428,14 @@ extern unsigned int kobjsize(const void *objp);
>   extern pgprot_t protection_map[16];
>   #endif
>   
> +#define DECLARE_VM_GET_PAGE_PROT \
> +pgprot_t vm_get_page_prot(unsigned long vm_flags)\
> +{\
> + return protection_map[vm_flags &\
> + (VM_READ | VM_WRITE | VM_EXEC | VM_SHARED)];\
> +}\
> +EXPORT_SYMBOL(vm_get_page_prot);
> +
>   /*
>* The default fault flags that should be used by most of the
>* arch-specific page fault handlers.
> diff --git a/mm/mmap.c b/mm/mmap.c
> index b01f0280bda2..55c30aee3999 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -123,11 +123,7 @@ pgprot_t protection_map[16] __ro_after_init = {
>   #endif
>   
>   #ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
> -pgprot_t vm_get_page_prot(unsigned long vm_flags)
> -{
> - return protection_map[vm_flags & (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)];
> -}
> -EXPORT_SYMBOL(vm_get_page_prot);
> +DECLARE_VM_GET_PAGE_PROT
>   #endif  /* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
>   
>   static pgprot_t vm_pgprot_modify(pgprot_t oldprot, unsigned long vm_flags)
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V4 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT

[Christophe Leroy]

Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
> protection_map[] has already been moved inside those platforms which enable
> 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 
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 

Reviewed-by: Christophe Leroy 

> ---
>   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];
>   #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 = {
>   [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

Re: [PATCH V4 03/26] powerpc/mm: Move protection_map[] inside the platform

[Christophe Leroy]

Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
> This moves protection_map[] inside the platform and while here, also enable
> ARCH_HAS_VM_GET_PAGE_PROT on 32 bit platforms via DECLARE_VM_GET_PAGE_PROT.
> 
> Cc: Michael Ellerman 
> Cc: Paul Mackerras 
> Cc: Nicholas Piggin 
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 

Reviewed-by: Christophe Leroy 

> ---
>   arch/powerpc/Kconfig   |  2 +-
>   arch/powerpc/include/asm/pgtable.h | 20 +---
>   arch/powerpc/mm/pgtable.c  | 24 
>   3 files changed, 26 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index c2ce2e60c8f0..1035d172c7dd 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -140,7 +140,7 @@ config PPC
>   select ARCH_HAS_TICK_BROADCAST  if GENERIC_CLOCKEVENTS_BROADCAST
>   select ARCH_HAS_UACCESS_FLUSHCACHE
>   select ARCH_HAS_UBSAN_SANITIZE_ALL
> - select ARCH_HAS_VM_GET_PAGE_PROTif PPC_BOOK3S_64
> + select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG
>   select ARCH_KEEP_MEMBLOCK
>   select ARCH_MIGHT_HAVE_PC_PARPORT
> diff --git a/arch/powerpc/include/asm/pgtable.h 
> b/arch/powerpc/include/asm/pgtable.h
> index d564d0ecd4cd..bf98db844579 100644
> --- a/arch/powerpc/include/asm/pgtable.h
> +++ b/arch/powerpc/include/asm/pgtable.h
> @@ -20,25 +20,6 @@ struct mm_struct;
>   #include 
>   #endif /* !CONFIG_PPC_BOOK3S */
>   
> -/* Note due to the way vm flags are laid out, the bits are XWR */
> -#define __P000   PAGE_NONE
> -#define __P001   PAGE_READONLY
> -#define __P010   PAGE_COPY
> -#define __P011   PAGE_COPY
> -#define __P100   PAGE_READONLY_X
> -#define __P101   PAGE_READONLY_X
> -#define __P110   PAGE_COPY_X
> -#define __P111   PAGE_COPY_X
> -
> -#define __S000   PAGE_NONE
> -#define __S001   PAGE_READONLY
> -#define __S010   PAGE_SHARED
> -#define __S011   PAGE_SHARED
> -#define __S100   PAGE_READONLY_X
> -#define __S101   PAGE_READONLY_X
> -#define __S110   PAGE_SHARED_X
> -#define __S111   PAGE_SHARED_X
> -
>   #ifndef __ASSEMBLY__
>   
>   #ifndef MAX_PTRS_PER_PGD
> @@ -79,6 +60,7 @@ extern void paging_init(void);
>   void poking_init(void);
>   
>   extern unsigned long ioremap_bot;
> +extern pgprot_t protection_map[16] __ro_after_init;
>   
>   /*
>* kern_addr_valid is intended to indicate whether an address is a valid
> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
> index e6166b71d36d..618f30d35b17 100644
> --- a/arch/powerpc/mm/pgtable.c
> +++ b/arch/powerpc/mm/pgtable.c
> @@ -472,3 +472,27 @@ pte_t *__find_linux_pte(pgd_t *pgdir, unsigned long ea,
>   return ret_pte;
>   }
>   EXPORT_SYMBOL_GPL(__find_linux_pte);
> +
> +/* Note due to the way vm flags are laid out, the bits are XWR */
> +pgprot_t protection_map[16] __ro_after_init = {
> + [VM_NONE]   = PAGE_NONE,
> + [VM_READ]   = PAGE_READONLY,
> + [VM_WRITE]  = PAGE_COPY,
> + [VM_WRITE | VM_READ]= PAGE_COPY,
> + [VM_EXEC]   = PAGE_READONLY_X,
> + [VM_EXEC | VM_READ] = PAGE_READONLY_X,
> + [VM_EXEC | VM_WRITE]= PAGE_COPY_X,
> + [VM_EXEC | VM_WRITE | VM_READ]  = PAGE_COPY_X,
> + [VM_SHARED] = PAGE_NONE,
> + [VM_SHARED | VM_READ]   = PAGE_READONLY,
> + [VM_SHARED | VM_WRITE]  = PAGE_SHARED,
> + [VM_SHARED | VM_WRITE | VM_READ]= PAGE_SHARED,
> + [VM_SHARED | VM_EXEC]   = PAGE_READONLY_X,
> + [VM_SHARED | VM_EXEC | VM_READ] = PAGE_READONLY_X,
> + [VM_SHARED | VM_EXEC | VM_WRITE]= PAGE_SHARED_X,
> + [VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]  = PAGE_SHARED_X
> +};
> +
> +#ifndef CONFIG_PPC_BOOK3S_64
> +DECLARE_VM_GET_PAGE_PROT
> +#endif
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V4 01/26] mm/mmap: Build protect protection_map[] with __P000

[Christophe Leroy]

Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
> Build protect generic protection_map[] array with __P000, so that it can be
> moved inside all the platforms one after the other. Otherwise there will be
> build failures during this process. CONFIG_ARCH_HAS_VM_GET_PAGE_PROT cannot
> be used for this purpose as only certain platforms enable this config now.
> 
> Cc: Andrew Morton 
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Suggested-by: Christophe Leroy 
> Signed-off-by: Anshuman Khandual 

Reviewed-by: Christophe Leroy 

> ---
>   include/linux/mm.h | 2 ++
>   mm/mmap.c  | 2 ++
>   2 files changed, 4 insertions(+)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index bc8f326be0ce..47bfe038d46e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -424,7 +424,9 @@ 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
>   extern pgprot_t protection_map[16];
> +#endif
>   
>   /*
>* The default fault flags that should be used by most of the
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 61e6135c54ef..b01f0280bda2 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -101,6 +101,7 @@ static void unmap_region(struct mm_struct *mm,
>*  w: (no) no
>*  x: (yes) yes
>*/
> +#ifdef __P000
>   pgprot_t protection_map[16] __ro_after_init = {
>   [VM_NONE]   = __P000,
>   [VM_READ]   = __P001,
> @@ -119,6 +120,7 @@ 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
>   pgprot_t vm_get_page_prot(unsigned long vm_flags)
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V4 26/26] mm/mmap: Drop ARCH_HAS_VM_GET_PAGE_PROT

[Christophe Leroy]

Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
> Now all the platforms enable ARCH_HAS_GET_PAGE_PROT. They define and export
> own vm_get_page_prot() whether custom or standard DECLARE_VM_GET_PAGE_PROT.
> Hence there is no need for default generic fallback for vm_get_page_prot().
> Just drop this fallback and also ARCH_HAS_GET_PAGE_PROT mechanism.
> 
> Cc: Andrew Morton 
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 
> ---
>   arch/alpha/Kconfig  |  1 -
>   arch/arc/Kconfig|  1 -
>   arch/arm/Kconfig|  1 -
>   arch/arm64/Kconfig  |  1 -
>   arch/csky/Kconfig   |  1 -
>   arch/hexagon/Kconfig|  1 -
>   arch/ia64/Kconfig   |  1 -
>   arch/loongarch/Kconfig  |  1 -
>   arch/m68k/Kconfig   |  1 -
>   arch/microblaze/Kconfig |  1 -
>   arch/mips/Kconfig   |  1 -
>   arch/nios2/Kconfig  |  1 -
>   arch/openrisc/Kconfig   |  1 -
>   arch/parisc/Kconfig |  1 -
>   arch/powerpc/Kconfig|  1 -
>   arch/riscv/Kconfig  |  1 -
>   arch/s390/Kconfig   |  1 -
>   arch/sh/Kconfig |  1 -
>   arch/sparc/Kconfig  |  1 -
>   arch/um/Kconfig |  1 -
>   arch/x86/Kconfig|  1 -
>   arch/xtensa/Kconfig |  1 -
>   include/linux/mm.h  |  3 ---
>   mm/Kconfig  |  3 ---
>   mm/mmap.c   | 22 --
>   25 files changed, 50 deletions(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 43db3bd49071..3557fe83d124 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -101,28 +101,6 @@ static void unmap_region(struct mm_struct *mm,
>*  w: (no) no
>*  x: (yes) yes
>*/

The above comment is not orphaned. I think it should go in linux/mm.h

> -#ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
> -pgprot_t protection_map[16] __ro_after_init = {
> - [VM_NONE]   = __P000,
> - [VM_READ]   = __P001,
> - [VM_WRITE]  = __P010,
> - [VM_WRITE | VM_READ]= __P011,
> - [VM_EXEC]   = __P100,
> - [VM_EXEC | VM_READ] = __P101,
> - [VM_EXEC | VM_WRITE]= __P110,
> - [VM_EXEC | VM_WRITE | VM_READ]  = __P111,
> - [VM_SHARED] = __S000,
> - [VM_SHARED | VM_READ]   = __S001,
> - [VM_SHARED | VM_WRITE]  = __S010,
> - [VM_SHARED | VM_WRITE | VM_READ]= __S011,
> - [VM_SHARED | VM_EXEC]   = __S100,
> - [VM_SHARED | VM_EXEC | VM_READ] = __S101,
> - [VM_SHARED | VM_EXEC | VM_WRITE]= __S110,
> - [VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]  = __S111
> -};
> -DECLARE_VM_GET_PAGE_PROT
> -#endif   /* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
> -
>   static pgprot_t vm_pgprot_modify(pgprot_t oldprot, unsigned long vm_flags)
>   {
>   return pgprot_modify(oldprot, vm_get_page_prot(vm_flags));
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V4 02/26] mm/mmap: Define DECLARE_VM_GET_PAGE_PROT

[Christophe Leroy]

Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
> This just converts the generic vm_get_page_prot() implementation into a new
> macro i.e DECLARE_VM_GET_PAGE_PROT which later can be used across platforms
> when enabling them with ARCH_HAS_VM_GET_PAGE_PROT. This does not create any
> functional change.
> 
> Cc: Andrew Morton 
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Suggested-by: Christoph Hellwig 
> Signed-off-by: Anshuman Khandual 
> ---
>   include/linux/mm.h | 8 
>   mm/mmap.c  | 6 +-
>   2 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 47bfe038d46e..237828c2bae2 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -428,6 +428,14 @@ extern unsigned int kobjsize(const void *objp);
>   extern pgprot_t protection_map[16];
>   #endif
>   

I think the comment above protection_map[16] in mm/mmap.c should be 
moved here.

> +#define DECLARE_VM_GET_PAGE_PROT \
> +pgprot_t vm_get_page_prot(unsigned long vm_flags)\
> +{\
> + return protection_map[vm_flags &\
> + (VM_READ | VM_WRITE | VM_EXEC | VM_SHARED)];\
> +}\
> +EXPORT_SYMBOL(vm_get_page_prot);
> +
>   /*
>* The default fault flags that should be used by most of the
>* arch-specific page fault handlers.
> diff --git a/mm/mmap.c b/mm/mmap.c
> index b01f0280bda2..55c30aee3999 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -123,11 +123,7 @@ pgprot_t protection_map[16] __ro_after_init = {
>   #endif
>   
>   #ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
> -pgprot_t vm_get_page_prot(unsigned long vm_flags)
> -{
> - return protection_map[vm_flags & (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)];
> -}
> -EXPORT_SYMBOL(vm_get_page_prot);
> +DECLARE_VM_GET_PAGE_PROT
>   #endif  /* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
>   
>   static pgprot_t vm_pgprot_modify(pgprot_t oldprot, unsigned long vm_flags)
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V4 08/26] microblaze/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT

[Christophe Leroy]

Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
> This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
> vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
> up a private and static protection_map[] array. Subsequently all __SXXX and
> __PXXX macros can be dropped which are no longer needed.

In this patch and all following ones, can't protection_map[] be const 
instead of __ro_after_init ?

> 
> Cc: Michal Simek 
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 
> ---
>   arch/microblaze/Kconfig   |  1 +
>   arch/microblaze/include/asm/pgtable.h | 17 -
>   arch/microblaze/mm/init.c | 20 
>   3 files changed, 21 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index 8cf429ad1c84..15f91ba8a0c4 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -7,6 +7,7 @@ config MICROBLAZE
>   select ARCH_HAS_GCOV_PROFILE_ALL
>   select ARCH_HAS_SYNC_DMA_FOR_CPU
>   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> + select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_MIGHT_HAVE_PC_PARPORT
>   select ARCH_WANT_IPC_PARSE_VERSION
>   select BUILDTIME_TABLE_SORT
> diff --git a/arch/microblaze/include/asm/pgtable.h 
> b/arch/microblaze/include/asm/pgtable.h
> index 0c72646370e1..ba348e997dbb 100644
> --- a/arch/microblaze/include/asm/pgtable.h
> +++ b/arch/microblaze/include/asm/pgtable.h
> @@ -204,23 +204,6 @@ extern pte_t *va_to_pte(unsigned long address);
>* We consider execute permission the same as read.
>* Also, write permissions imply read permissions.
>*/
> -#define __P000   PAGE_NONE
> -#define __P001   PAGE_READONLY_X
> -#define __P010   PAGE_COPY
> -#define __P011   PAGE_COPY_X
> -#define __P100   PAGE_READONLY
> -#define __P101   PAGE_READONLY_X
> -#define __P110   PAGE_COPY
> -#define __P111   PAGE_COPY_X
> -
> -#define __S000   PAGE_NONE
> -#define __S001   PAGE_READONLY_X
> -#define __S010   PAGE_SHARED
> -#define __S011   PAGE_SHARED_X
> -#define __S100   PAGE_READONLY
> -#define __S101   PAGE_READONLY_X
> -#define __S110   PAGE_SHARED
> -#define __S111   PAGE_SHARED_X
>   
>   #ifndef __ASSEMBLY__
>   /*
> diff --git a/arch/microblaze/mm/init.c b/arch/microblaze/mm/init.c
> index f4e503461d24..315fd5024f00 100644
> --- a/arch/microblaze/mm/init.c
> +++ b/arch/microblaze/mm/init.c
> @@ -285,3 +285,23 @@ void * __ref zalloc_maybe_bootmem(size_t size, gfp_t 
> mask)
>   
>   return p;
>   }
> +
> +static pgprot_t protection_map[16] __ro_after_init = {
> + [VM_NONE]   = PAGE_NONE,
> + [VM_READ]   = PAGE_READONLY_X,
> + [VM_WRITE]  = PAGE_COPY,
> + [VM_WRITE | VM_READ]= PAGE_COPY_X,
> + [VM_EXEC]   = PAGE_READONLY,
> + [VM_EXEC | VM_READ] = PAGE_READONLY_X,
> + [VM_EXEC | VM_WRITE]= PAGE_COPY,
> + [VM_EXEC | VM_WRITE | VM_READ]  = PAGE_COPY_X,
> + [VM_SHARED] = PAGE_NONE,
> + [VM_SHARED | VM_READ]   = PAGE_READONLY_X,
> + [VM_SHARED | VM_WRITE]  = PAGE_SHARED,
> + [VM_SHARED | VM_WRITE | VM_READ]= PAGE_SHARED_X,
> + [VM_SHARED | VM_EXEC]   = PAGE_READONLY,
> + [VM_SHARED | VM_EXEC | VM_READ] = PAGE_READONLY_X,
> + [VM_SHARED | VM_EXEC | VM_WRITE]= PAGE_SHARED,
> + [VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]  = PAGE_SHARED_X
> +};
> +DECLARE_VM_GET_PAGE_PROT
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V4 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT

[Christophe Leroy]

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 "

> 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 
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 
> ---
>   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.

>   #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 ?
And it could also be 'const' instead of __ro_after_init.

>   [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

Re: [PATCH V4 03/26] powerpc/mm: Move protection_map[] inside the platform

[Christophe Leroy]

Le 24/06/2022 à 06:43, Anshuman Khandual a écrit :
> This moves protection_map[] inside the platform and while here, also enable
> ARCH_HAS_VM_GET_PAGE_PROT on 32 bit platforms via DECLARE_VM_GET_PAGE_PROT.

Not only 32 bit platforms, also nohash 64 (aka book3e/64)

> 
> Cc: Michael Ellerman 
> Cc: Paul Mackerras 
> Cc: Nicholas Piggin 
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 
> ---
>   arch/powerpc/Kconfig   |  2 +-
>   arch/powerpc/include/asm/pgtable.h | 20 +---
>   arch/powerpc/mm/pgtable.c  | 24 
>   3 files changed, 26 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index c2ce2e60c8f0..1035d172c7dd 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -140,7 +140,7 @@ config PPC
>   select ARCH_HAS_TICK_BROADCAST  if GENERIC_CLOCKEVENTS_BROADCAST
>   select ARCH_HAS_UACCESS_FLUSHCACHE
>   select ARCH_HAS_UBSAN_SANITIZE_ALL
> - select ARCH_HAS_VM_GET_PAGE_PROTif PPC_BOOK3S_64
> + select ARCH_HAS_VM_GET_PAGE_PROT
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG
>   select ARCH_KEEP_MEMBLOCK
>   select ARCH_MIGHT_HAVE_PC_PARPORT
> diff --git a/arch/powerpc/include/asm/pgtable.h 
> b/arch/powerpc/include/asm/pgtable.h
> index d564d0ecd4cd..bf98db844579 100644
> --- a/arch/powerpc/include/asm/pgtable.h
> +++ b/arch/powerpc/include/asm/pgtable.h
> @@ -20,25 +20,6 @@ struct mm_struct;
>   #include 
>   #endif /* !CONFIG_PPC_BOOK3S */
>   
> -/* Note due to the way vm flags are laid out, the bits are XWR */
> -#define __P000   PAGE_NONE
> -#define __P001   PAGE_READONLY
> -#define __P010   PAGE_COPY
> -#define __P011   PAGE_COPY
> -#define __P100   PAGE_READONLY_X
> -#define __P101   PAGE_READONLY_X
> -#define __P110   PAGE_COPY_X
> -#define __P111   PAGE_COPY_X
> -
> -#define __S000   PAGE_NONE
> -#define __S001   PAGE_READONLY
> -#define __S010   PAGE_SHARED
> -#define __S011   PAGE_SHARED
> -#define __S100   PAGE_READONLY_X
> -#define __S101   PAGE_READONLY_X
> -#define __S110   PAGE_SHARED_X
> -#define __S111   PAGE_SHARED_X
> -
>   #ifndef __ASSEMBLY__
>   
>   #ifndef MAX_PTRS_PER_PGD
> @@ -79,6 +60,7 @@ extern void paging_init(void);
>   void poking_init(void);
>   
>   extern unsigned long ioremap_bot;
> +extern pgprot_t protection_map[16] __ro_after_init;
>   
>   /*
>* kern_addr_valid is intended to indicate whether an address is a valid
> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
> index e6166b71d36d..618f30d35b17 100644
> --- a/arch/powerpc/mm/pgtable.c
> +++ b/arch/powerpc/mm/pgtable.c
> @@ -472,3 +472,27 @@ pte_t *__find_linux_pte(pgd_t *pgdir, unsigned long ea,
>   return ret_pte;
>   }
>   EXPORT_SYMBOL_GPL(__find_linux_pte);
> +
> +/* Note due to the way vm flags are laid out, the bits are XWR */
> +pgprot_t protection_map[16] __ro_after_init = {

I can't see any place where protection_map[] gets modified. This could 
be made const.

> + [VM_NONE]   = PAGE_NONE,
> + [VM_READ]   = PAGE_READONLY,
> + [VM_WRITE]  = PAGE_COPY,
> + [VM_WRITE | VM_READ]= PAGE_COPY,
> + [VM_EXEC]   = PAGE_READONLY_X,
> + [VM_EXEC | VM_READ] = PAGE_READONLY_X,
> + [VM_EXEC | VM_WRITE]= PAGE_COPY_X,
> + [VM_EXEC | VM_WRITE | VM_READ]  = PAGE_COPY_X,
> + [VM_SHARED] = PAGE_NONE,
> + [VM_SHARED | VM_READ]   = PAGE_READONLY,
> + [VM_SHARED | VM_WRITE]  = PAGE_SHARED,
> + [VM_SHARED | VM_WRITE | VM_READ]= PAGE_SHARED,
> + [VM_SHARED | VM_EXEC]   = PAGE_READONLY_X,
> + [VM_SHARED | VM_EXEC | VM_READ] = PAGE_READONLY_X,
> + [VM_SHARED | VM_EXEC | VM_WRITE]= PAGE_SHARED_X,
> + [VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]  = PAGE_SHARED_X
> +};
> +
> +#ifndef CONFIG_PPC_BOOK3S_64
> +DECLARE_VM_GET_PAGE_PROT
> +#endif
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT

[Christophe Leroy]

Le 02/03/2022 à 04:22, Anshuman Khandual a écrit :
> 
> 
> On 3/1/22 1:46 PM, Christophe Leroy wrote:
>>
>>
>> Le 01/03/2022 à 01:31, Russell King (Oracle) a écrit :
>>> On Tue, Mar 01, 2022 at 05:30:41AM +0530, Anshuman Khandual wrote:
>>>> On 2/28/22 4:27 PM, Russell King (Oracle) wrote:
>>>>> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote:
>>>>>> This defines and exports a platform specific custom vm_get_page_prot() 
>>>>>> via
>>>>>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX
>>>>>> macros can be dropped which are no longer needed.
>>>>>
>>>>> What I would really like to know is why having to run _code_ to work out
>>>>> what the page protections need to be is better than looking it up in a
>>>>> table.
>>>>>
>>>>> Not only is this more expensive in terms of CPU cycles, it also brings
>>>>> additional code size with it.
>>>>>
>>>>> I'm struggling to see what the benefit is.
>>>>
>>>> Currently vm_get_page_prot() is also being _run_ to fetch required page
>>>> protection values. Although that is being run in the core MM and from a
>>>> platform perspective __SXXX, __PXXX are just being exported for a table.
>>>> Looking it up in a table (and applying more constructs there after) is
>>>> not much different than a clean switch case statement in terms of CPU
>>>> usage. So this is not more expensive in terms of CPU cycles.
>>>
>>> I disagree.
>>
>> So do I.
>>
>>>
>>> However, let's base this disagreement on some evidence. Here is the
>>> present 32-bit ARM implementation:
>>>
>>> 0048 :
>>> 48:   e20fand r0, r0, #15
>>> 4c:   e3003000movwr3, #0
>>>   4c: R_ARM_MOVW_ABS_NC   .LANCHOR1
>>> 50:   e3403000movtr3, #0
>>>   50: R_ARM_MOVT_ABS  .LANCHOR1
>>> 54:   e7930100ldr r0, [r3, r0, lsl #2]
>>> 58:   e12fff1ebx  lr
>>>
>>> That is five instructions long.
>>
>> On ppc32 I get:
>>
>> 0094 :
>> 94:  3d 20 00 00 lis r9,0
>>  96: R_PPC_ADDR16_HA .data..ro_after_init
>> 98:  54 84 16 ba rlwinm  r4,r4,2,26,29
>> 9c:  39 29 00 00 addir9,r9,0
>>  9e: R_PPC_ADDR16_LO .data..ro_after_init
>> a0:  7d 29 20 2e lwzxr9,r9,r4
>> a4:  91 23 00 00 stw r9,0(r3)
>> a8:  4e 80 00 20 blr
>>
>>
>>>
>>> Please show that your new implementation is not more expensive on
>>> 32-bit ARM. Please do so by building a 32-bit kernel, and providing
>>> the disassembly.
>>
>> With your series I get:
>>
>>  :
>>  0:  3d 20 00 00 lis r9,0
>>  2: R_PPC_ADDR16_HA  .rodata
>>  4:  39 29 00 00 addir9,r9,0
>>  6: R_PPC_ADDR16_LO  .rodata
>>  8:  54 84 16 ba rlwinm  r4,r4,2,26,29
>>  c:  7d 49 20 2e lwzxr10,r9,r4
>> 10:  7d 4a 4a 14 add r10,r10,r9
>> 14:  7d 49 03 a6 mtctr   r10
>> 18:  4e 80 04 20 bctr
>> 1c:  39 20 03 15 li  r9,789
>> 20:  91 23 00 00 stw r9,0(r3)
>> 24:  4e 80 00 20 blr
>> 28:  39 20 01 15 li  r9,277
>> 2c:  91 23 00 00 stw r9,0(r3)
>> 30:  4e 80 00 20 blr
>> 34:  39 20 07 15 li  r9,1813
>> 38:  91 23 00 00 stw r9,0(r3)
>> 3c:  4e 80 00 20 blr
>> 40:  39 20 05 15 li  r9,1301
>> 44:  91 23 00 00 stw r9,0(r3)
>> 48:  4e 80 00 20 blr
>> 4c:  39 20 01 11 li  r9,273
>> 50:  4b ff ff d0 b   20 
>>
>>
>> That is definitely more expensive, it implements a table of branches.
> 
> Okay, will split out the PPC32 implementation that retains existing
> table look up method. Also planning to keep that inside same file
> (arch/powerpc/mm/mmap.c), unless you have a difference preference.

My point was not to get something specific for PPC32, but to amplify on 
Russell's objection.

As this is bad for ARM and

Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT

[Christophe Leroy]

Le 01/03/2022 à 01:31, Russell King (Oracle) a écrit :
> On Tue, Mar 01, 2022 at 05:30:41AM +0530, Anshuman Khandual wrote:
>> On 2/28/22 4:27 PM, Russell King (Oracle) wrote:
>>> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote:
 This defines and exports a platform specific custom vm_get_page_prot() via
 subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX
 macros can be dropped which are no longer needed.
>>>
>>> What I would really like to know is why having to run _code_ to work out
>>> what the page protections need to be is better than looking it up in a
>>> table.
>>>
>>> Not only is this more expensive in terms of CPU cycles, it also brings
>>> additional code size with it.
>>>
>>> I'm struggling to see what the benefit is.
>>
>> Currently vm_get_page_prot() is also being _run_ to fetch required page
>> protection values. Although that is being run in the core MM and from a
>> platform perspective __SXXX, __PXXX are just being exported for a table.
>> Looking it up in a table (and applying more constructs there after) is
>> not much different than a clean switch case statement in terms of CPU
>> usage. So this is not more expensive in terms of CPU cycles.
> 
> I disagree.

So do I.

> 
> However, let's base this disagreement on some evidence. Here is the
> present 32-bit ARM implementation:
> 
> 0048 :
>48:   e20fand r0, r0, #15
>4c:   e3003000movwr3, #0
>  4c: R_ARM_MOVW_ABS_NC   .LANCHOR1
>50:   e3403000movtr3, #0
>  50: R_ARM_MOVT_ABS  .LANCHOR1
>54:   e7930100ldr r0, [r3, r0, lsl #2]
>58:   e12fff1ebx  lr
> 
> That is five instructions long.

On ppc32 I get:

0094 :
   94:  3d 20 00 00 lis r9,0
96: R_PPC_ADDR16_HA .data..ro_after_init
   98:  54 84 16 ba rlwinm  r4,r4,2,26,29
   9c:  39 29 00 00 addir9,r9,0
9e: R_PPC_ADDR16_LO .data..ro_after_init
   a0:  7d 29 20 2e lwzxr9,r9,r4
   a4:  91 23 00 00 stw r9,0(r3)
   a8:  4e 80 00 20 blr


> 
> Please show that your new implementation is not more expensive on
> 32-bit ARM. Please do so by building a 32-bit kernel, and providing
> the disassembly.

With your series I get:

 :
0:  3d 20 00 00 lis r9,0
2: R_PPC_ADDR16_HA  .rodata
4:  39 29 00 00 addir9,r9,0
6: R_PPC_ADDR16_LO  .rodata
8:  54 84 16 ba rlwinm  r4,r4,2,26,29
c:  7d 49 20 2e lwzxr10,r9,r4
   10:  7d 4a 4a 14 add r10,r10,r9
   14:  7d 49 03 a6 mtctr   r10
   18:  4e 80 04 20 bctr
   1c:  39 20 03 15 li  r9,789
   20:  91 23 00 00 stw r9,0(r3)
   24:  4e 80 00 20 blr
   28:  39 20 01 15 li  r9,277
   2c:  91 23 00 00 stw r9,0(r3)
   30:  4e 80 00 20 blr
   34:  39 20 07 15 li  r9,1813
   38:  91 23 00 00 stw r9,0(r3)
   3c:  4e 80 00 20 blr
   40:  39 20 05 15 li  r9,1301
   44:  91 23 00 00 stw r9,0(r3)
   48:  4e 80 00 20 blr
   4c:  39 20 01 11 li  r9,273
   50:  4b ff ff d0 b   20 


That is definitely more expensive, it implements a table of branches.


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

Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good

[Christophe Leroy]

Le 18/02/2022 à 02:50, Al Viro a écrit :
> On Thu, Feb 17, 2022 at 07:20:11AM +0000, Christophe Leroy wrote:
> 
>> And we have also
>> user_access_begin()/user_read_access_begin()/user_write_access_begin()
>> which call access_ok() then do the real work. Could be made generic with
>> call to some arch specific __user_access_begin() and friends after the
>> access_ok() and eventually the might_fault().
> 
> Not a good idea, considering the fact that we do not want to invite
> uses of "faster" variants...

I'm not sure I understand your concern.

Today in powerpc we have:

static __must_check inline bool
user_read_access_begin(const void __user *ptr, size_t len)
{
if (unlikely(!access_ok(ptr, len)))
return false;

might_fault();

allow_read_from_user(ptr, len);
return true;
}

We could instead have a generic

static __must_check inline bool
user_read_access_begin(const void __user *ptr, size_t len)
{
if (unlikely(!access_ok(ptr, len)))
return false;

might_fault();

return arch_user_read_access_begin(ptr, len);
}

And then a powerpc specific

static __must_check __always_inline bool
arch_user_read_access_begin(const void __user *ptr, size_t len)
{
allow_read_from_user(ptr, len);
return true;
}
#define arch_user_read_access_begin arch_user_read_access_begin

And a generic fallback for arch_user_read_access_begin() that does 
nothing at all.

Do you mean that in that case people might be tempted to use 
arch_user_read_access_begin() instead of using user_read_access_begin() ?

If that's the case isn't it something we could verify via checkpatch.pl ?

Today it seems to be problematic that functions in asm/uaccess.h use 
access_ok(). Such an approach would allow to get rid of access_ok() use 
in architecture's uaccess.h

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

Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good

[Christophe Leroy]

Le 16/02/2022 à 14:13, Arnd Bergmann a écrit :
> From: Arnd Bergmann 
> 
> Christoph Hellwig and a few others spent a huge effort on removing
> set_fs() from most of the important architectures, but about half the
> other architectures were never completed even though most of them don't
> actually use set_fs() at all.
> 
> I did a patch for microblaze at some point, which turned out to be fairly
> generic, and now ported it to most other architectures, using new generic
> implementations of access_ok() and __{get,put}_kernel_nocheck().
> 
> Three architectures (sparc64, ia64, and sh) needed some extra work,
> which I also completed.
> 
> The final series contains extra cleanup changes that touch all
> architectures. Please review and test these, so we can merge them
> for v5.18.

As a further cleanup, have you thought about making a generic version of 
clear_user() ? On almost all architectures, clear_user() does an 
access_ok() then calls __clear_user() or similar.

Maybe also the same with put_user() and get_user() ? After all it is 
just access_ok() followed by __put_user() or __get_user() ? It seems 
more tricky though, as some architectures seems to have less trivial 
stuff there.

I also see all architectures have a prototype for strncpy_from_user() 
and strnlen_user(). Could be a common prototype instead when we have 
GENERIC_STRNCPY_FROM_USER / GENERIC_STRNLEN_USER

And we have also 
user_access_begin()/user_read_access_begin()/user_write_access_begin() 
which call access_ok() then do the real work. Could be made generic with 
call to some arch specific __user_access_begin() and friends after the 
access_ok() and eventually the might_fault().

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

Re: [PATCH 08/14] arm64: simplify access_ok()

[Christophe Leroy]

Le 15/02/2022 à 10:12, Arnd Bergmann a écrit :
> On Tue, Feb 15, 2022 at 9:17 AM Ard Biesheuvel  wrote:
>> On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann  wrote:
>>> From: Arnd Bergmann 
>>>
>>
>> With set_fs() out of the picture, wouldn't it be sufficient to check
>> that bit #55 is clear? (the bit that selects between TTBR0 and TTBR1)
>> That would also remove the need to strip the tag from the address.
>>
>> Something like
>>
>>  asm goto("tbnz  %0, #55, %2 \n"
>>   "tbnz  %1, #55, %2 \n"
>>   :: "r"(addr), "r"(addr + size - 1) :: notok);
>>  return 1;
>> notok:
>>  return 0;
>>
>> with an additional sanity check on the size which the compiler could
>> eliminate for compile-time constant values.
> 
> That should work, but I don't see it as a clear enough advantage to
> have a custom implementation. For the constant-size case, it probably
> isn't better than a compiler-scheduled comparison against a
> constant limit, but it does hurt maintainability when the next person
> wants to change the behavior of access_ok() globally.
> 
> If we want to get into micro-optimizing uaccess, I think a better target
> would be a CONFIG_CC_HAS_ASM_GOTO_OUTPUT version
> of __get_user()/__put_user as we have on x86 and powerpc.
> 

There is also the user block accesses with 
user_access_begin()/user_access_end() together with unsafe_put_user() 
and unsafe_get_user() which allowed us to optimise user accesses on 
powerpc, especially in the signal code.

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

Re: [PATCH 3/3] memblock: cleanup memblock_free interface

[Christophe Leroy]

Le 23/09/2021 à 14:01, Mike Rapoport a écrit :

On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:



Le 23/09/2021 à 09:43, Mike Rapoport a écrit :

From: Mike Rapoport 

For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.

Introduce memblock_phys_free() for freeing physical ranges and repurpose
memblock_free() to free virtual pointers to make the following pairing
abundantly clear:

int memblock_phys_free(phys_addr_t base, phys_addr_t size);
phys_addr_t memblock_phys_alloc(phys_addr_t base, phys_addr_t size);

void *memblock_alloc(phys_addr_t size, phys_addr_t align);
void memblock_free(void *ptr, size_t size);

Replace intermediate memblock_free_ptr() with memblock_free() and drop
unnecessary aliases memblock_free_early() and memblock_free_early_nid().

Suggested-by: Linus Torvalds 
Signed-off-by: Mike Rapoport 
---



diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index 1a04e5bdf655..37826d8c4f74 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -723,7 +723,7 @@ void __init smp_save_dump_cpus(void)
/* Get the CPU registers */
smp_save_cpu_regs(sa, addr, is_boot_cpu, page);
}
-   memblock_free(page, PAGE_SIZE);
+   memblock_phys_free(page, PAGE_SIZE);
diag_amode31_ops.diag308_reset();
pcpu_set_smt(0);
   }
@@ -880,7 +880,7 @@ void __init smp_detect_cpus(void)
/* Add CPUs present at boot */
__smp_rescan_cpus(info, true);
-   memblock_free_early((unsigned long)info, sizeof(*info));
+   memblock_free(info, sizeof(*info));
   }
   /*


I'm a bit lost. IIUC memblock_free_early() and memblock_free() where
identical.


Yes, they were, but all calls to memblock_free_early() were using
__pa(vaddr) because they had a virtual address at hand.


I'm still not following. In the above memblock_free_early() was taking 
(unsigned long)info . Was it a bug ? It looks odd to hide bug fixes in 
such a big patch, should that bug fix go in patch 2 ?





In the first hunk memblock_free() gets replaced by memblock_phys_free()
In the second hunk memblock_free_early() gets replaced by memblock_free()


In the first hunk the memory is allocated with memblock_phys_alloc() and we
have a physical range to free. In the second hunk the memory is allocated
with memblock_alloc() and we are freeing a virtual pointer.
  

I think it would be easier to follow if you could split it in several
patches:


It was an explicit request from Linus to make it a single commit:

   but the actual commit can and should be just a single commit that just
   fixes 'memblock_free()' to have sane interfaces.

I don't feel strongly about splitting it (except my laziness really
objects), but I don't think doing the conversion in several steps worth the
churn.


The commit is quite big (55 files changed, approx 100 lines modified).

If done in the right order the change should be minimal.

It is rather not-easy to follow and review when a function that was 
existing (namely memblock_free() ) disappears and re-appears in the same 
commit but to do something different.


You do:
- memblock_free() ==> memblock_phys_free()
- memblock_free_ptr() ==> memblock_free()

At least you could split in two patches, the advantage would be that 
between first and second patch memblock() doesn't exist anymore so you 
can check you really don't have anymore user.





- First patch: Create memblock_phys_free() and change all relevant
memblock_free() to memblock_phys_free() - Or change memblock_free() to
memblock_phys_free() and make memblock_free() an alias of it.
- Second patch: Make memblock_free_ptr() become memblock_free() and change
all remaining callers to the new semantics (IIUC memblock_free(__pa(ptr))
becomes memblock_free(ptr) and make memblock_free_ptr() an alias of
memblock_free()
- Fourth patch: Replace and drop memblock_free_ptr()
- Fifth patch: Drop memblock_free_early() and memblock_free_early_nid() (All
users should have been upgraded to memblock_free_phys() in patch 1 or
memblock_free() in patch 2)

Christophe




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

Re: [PATCH 3/3] memblock: cleanup memblock_free interface

[Christophe Leroy]

Le 23/09/2021 à 09:43, Mike Rapoport a écrit :

From: Mike Rapoport 

For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.

Introduce memblock_phys_free() for freeing physical ranges and repurpose
memblock_free() to free virtual pointers to make the following pairing
abundantly clear:

int memblock_phys_free(phys_addr_t base, phys_addr_t size);
phys_addr_t memblock_phys_alloc(phys_addr_t base, phys_addr_t size);

void *memblock_alloc(phys_addr_t size, phys_addr_t align);
void memblock_free(void *ptr, size_t size);

Replace intermediate memblock_free_ptr() with memblock_free() and drop
unnecessary aliases memblock_free_early() and memblock_free_early_nid().

Suggested-by: Linus Torvalds 
Signed-off-by: Mike Rapoport 
---



diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index 1a04e5bdf655..37826d8c4f74 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -723,7 +723,7 @@ void __init smp_save_dump_cpus(void)
/* Get the CPU registers */
smp_save_cpu_regs(sa, addr, is_boot_cpu, page);
}
-   memblock_free(page, PAGE_SIZE);
+   memblock_phys_free(page, PAGE_SIZE);
diag_amode31_ops.diag308_reset();
pcpu_set_smt(0);
  }
@@ -880,7 +880,7 @@ void __init smp_detect_cpus(void)
  
  	/* Add CPUs present at boot */

__smp_rescan_cpus(info, true);
-   memblock_free_early((unsigned long)info, sizeof(*info));
+   memblock_free(info, sizeof(*info));
  }
  
  /*


I'm a bit lost. IIUC memblock_free_early() and memblock_free() where 
identical.


In the first hunk memblock_free() gets replaced by memblock_phys_free()
In the second hunk memblock_free_early() gets replaced by memblock_free()

I think it would be easier to follow if you could split it in several 
patches:
- First patch: Create memblock_phys_free() and change all relevant 
memblock_free() to memblock_phys_free() - Or change memblock_free() to 
memblock_phys_free() and make memblock_free() an alias of it.
- Second patch: Make memblock_free_ptr() become memblock_free() and 
change all remaining callers to the new semantics (IIUC 
memblock_free(__pa(ptr)) becomes memblock_free(ptr) and make 
memblock_free_ptr() an alias of memblock_free()

- Fourth patch: Replace and drop memblock_free_ptr()
- Fifth patch: Drop memblock_free_early() and memblock_free_early_nid() 
(All users should have been upgraded to memblock_free_phys() in patch 1 
or memblock_free() in patch 2)


Christophe

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

Re: [PATCH v3 resend 01/15] mm: add setup_initial_init_mm() helper

[Christophe Leroy]

Le 08/06/2021 à 16:53, Souptick Joarder a écrit :

On Tue, Jun 8, 2021 at 1:56 PM Kefeng Wang  wrote:


Add setup_initial_init_mm() helper to setup kernel text,
data and brk.

Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-c...@vger.kernel.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
Cc: linux-m...@lists.linux-m68k.org
Cc: openr...@lists.librecores.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-ri...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: x...@kernel.org
Signed-off-by: Kefeng Wang 
---
  include/linux/mm.h | 3 +++
  mm/init-mm.c   | 9 +
  2 files changed, 12 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index c274f75efcf9..02aa057540b7 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -244,6 +244,9 @@ int __add_to_page_cache_locked(struct page *page, struct 
address_space *mapping,

  #define lru_to_page(head) (list_entry((head)->prev, struct page, lru))

+void setup_initial_init_mm(void *start_code, void *end_code,
+  void *end_data, void *brk);
+


Gentle query -> is there any limitation to add inline functions in
setup_arch() functions ?


Kefeng just followed comment from Mike I guess, see 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210604070633.32363-2-wangkefeng.w...@huawei.com/#2696253


Christophe


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

Re: [PATCH v2 00/15] init_mm: cleanup ARCH's text/data/brk setup code

[Christophe Leroy]

Hi Kefeng,

Le 07/06/2021 à 02:55, Kefeng Wang a écrit :


On 2021/6/7 5:29, Mike Rapoport wrote:

Hello Kefeng,

On Fri, Jun 04, 2021 at 03:06:18PM +0800, Kefeng Wang wrote:

Add setup_initial_init_mm() helper, then use it
to cleanup the text, data and brk setup code.

v2:
- change argument from "char *" to "void *" setup_initial_init_mm()
   suggested by Geert Uytterhoeven
- use NULL instead of (void *)0 on h8300 and m68k
- collect ACKs

Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-c...@vger.kernel.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
Cc: linux-m...@lists.linux-m68k.org
Cc: openr...@lists.librecores.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-ri...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Kefeng Wang (15):
   mm: add setup_initial_init_mm() helper
   arc: convert to setup_initial_init_mm()
   arm: convert to setup_initial_init_mm()
   arm64: convert to setup_initial_init_mm()
   csky: convert to setup_initial_init_mm()
   h8300: convert to setup_initial_init_mm()
   m68k: convert to setup_initial_init_mm()
   nds32: convert to setup_initial_init_mm()
   nios2: convert to setup_initial_init_mm()
   openrisc: convert to setup_initial_init_mm()
   powerpc: convert to setup_initial_init_mm()
   riscv: convert to setup_initial_init_mm()
   s390: convert to setup_initial_init_mm()
   sh: convert to setup_initial_init_mm()
   x86: convert to setup_initial_init_mm()

I might be missing something, but AFAIU the init_mm.start_code and other
fields are not used really early so the new setup_initial_init_mm()
function can be called in the generic code outside setup_arch(), e.g in
mm_init().


Hi Mike， each architecture has their own value, not the same, eg m68K and

h8300, also the name of the text/code/brk is different in some arch, so I keep

unchanged.


What you could do is to define a __weak function that architectures can override and call that 
function from mm_init() as suggested by Mike,


Something like:

void __weak setup_initial_init_mm(void)
{
init_mm.start_code = (unsigned long)_stext;
init_mm.end_code = (unsigned long)_etext;
init_mm.end_data = (unsigned long)_edata;
init_mm.brk = (unsigned long)_end;
}

Then only the few architecture that are different would override it.

I see a few archictectures are usigne PAGE_OFFSET to set .start_code, but it is likely that this is 
equivalent to _stext.


Christophe

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

Re: [PATCH] init: consolidate trap_init()

[Christophe Leroy]

Le 14/04/2021 à 10:58, Jisheng Zhang a écrit :

Many architectures implement the trap_init() as NOP, since there is
no such default for trap_init(), this empty stub is duplicated among
these architectures. Provide a generic but weak NOP implementation
to drop the empty stubs of trap_init() in these architectures.


You define the weak function in the __init section.

Most but not all architectures had it in __init section.

And the remaining ones may not be defined in __init section. For instance look at the one in alpha 
architecture.


Have you checked that it is not a problem ? It would be good to say something about it in the commit 
description.





Signed-off-by: Jisheng Zhang 
---
  arch/arc/kernel/traps.c  |  5 -
  arch/arm/kernel/traps.c  |  5 -
  arch/h8300/kernel/traps.c| 13 -
  arch/hexagon/kernel/traps.c  |  4 
  arch/nds32/kernel/traps.c|  5 -
  arch/nios2/kernel/traps.c|  5 -
  arch/openrisc/kernel/traps.c |  5 -
  arch/parisc/kernel/traps.c   |  4 
  arch/powerpc/kernel/traps.c  |  5 -
  arch/riscv/kernel/traps.c|  5 -
  arch/um/kernel/trap.c|  4 
  init/main.c  |  2 ++
  12 files changed, 2 insertions(+), 60 deletions(-)

diff --git a/init/main.c b/init/main.c
index 53b278845b88..4bdbe2928530 100644
--- a/init/main.c
+++ b/init/main.c
@@ -790,6 +790,8 @@ static inline void initcall_debug_enable(void)
  }
  #endif
  
+void __init __weak trap_init(void) { }

+


I think in a C file we don't try to save space as much as in a header file.

I would prefer something like:


void __init __weak trap_init(void)
{
}



  /* Report memory auto-initialization states for this boot. */
  static void __init report_meminit(void)
  {



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

Re: [PATCH] mm: Define ARCH_HAS_FIRST_USER_ADDRESS

[Christophe Leroy]

Le 14/04/2021 à 07:59, Anshuman Khandual a écrit :



On 4/14/21 10:52 AM, Christophe Leroy wrote:



Le 14/04/2021 à 04:54, Anshuman Khandual a écrit :

Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
for those platforms which would override generic default FIRST_USER_ADDRESS
value 0UL. This makes it much cleaner with reduced code.

Cc: linux-al...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-c...@vger.kernel.org
Cc: linux-hexa...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-m...@vger.kernel.org
Cc: openr...@lists.librecores.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-ri...@lists.infradead.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux...@lists.infradead.org
Cc: linux-xte...@linux-xtensa.org
Cc: x...@kernel.org
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
   arch/alpha/include/asm/pgtable.h | 1 -
   arch/arc/include/asm/pgtable.h   | 6 --
   arch/arm/Kconfig | 1 +
   arch/arm64/include/asm/pgtable.h | 2 --
   arch/csky/include/asm/pgtable.h  | 1 -
   arch/hexagon/include/asm/pgtable.h   | 3 ---
   arch/ia64/include/asm/pgtable.h  | 1 -
   arch/m68k/include/asm/pgtable_mm.h   | 1 -
   arch/microblaze/include/asm/pgtable.h    | 2 --
   arch/mips/include/asm/pgtable-32.h   | 1 -
   arch/mips/include/asm/pgtable-64.h   | 1 -
   arch/nds32/Kconfig   | 1 +
   arch/nios2/include/asm/pgtable.h | 2 --
   arch/openrisc/include/asm/pgtable.h  | 1 -
   arch/parisc/include/asm/pgtable.h    | 2 --
   arch/powerpc/include/asm/book3s/pgtable.h    | 1 -
   arch/powerpc/include/asm/nohash/32/pgtable.h | 1 -
   arch/powerpc/include/asm/nohash/64/pgtable.h | 2 --
   arch/riscv/include/asm/pgtable.h | 2 --
   arch/s390/include/asm/pgtable.h  | 2 --
   arch/sh/include/asm/pgtable.h    | 2 --
   arch/sparc/include/asm/pgtable_32.h  | 1 -
   arch/sparc/include/asm/pgtable_64.h  | 3 ---
   arch/um/include/asm/pgtable-2level.h | 1 -
   arch/um/include/asm/pgtable-3level.h | 1 -
   arch/x86/include/asm/pgtable_types.h | 2 --
   arch/xtensa/include/asm/pgtable.h    | 1 -
   include/linux/mm.h   | 4 
   mm/Kconfig   | 4 
   29 files changed, 10 insertions(+), 43 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8ba434287387..47098ccd715e 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -46,6 +46,10 @@ extern int sysctl_page_lock_unfairness;
     void init_mm_internals(void);
   +#ifndef ARCH_HAS_FIRST_USER_ADDRESS


I guess you didn't test it . :)


In fact I did :) Though just booted it on arm64 and cross compiled on
multiple others platforms.



should be #ifndef CONFIG_ARCH_HAS_FIRST_USER_ADDRESS


Right, meant that instead.




+#define FIRST_USER_ADDRESS    0UL
+#endif


But why do we need a config option at all for that ?

Why not just:

#ifndef FIRST_USER_ADDRESS
#define FIRST_USER_ADDRESS    0UL
#endif


This sounds simpler. But just wondering, would not there be any possibility
of build problems due to compilation sequence between arch and generic code ?



For sure it has to be addresses carefully, but there are already a lot of stuff like that around 
pgtables.h


For instance, pte_offset_kernel() has a generic definition in linux/pgtables.h based on whether it 
is already defined or not.


Taking into account that FIRST_USER_ADDRESS is today in the architectures's asm/pgtables.h, I think 
putting the fallback definition in linux/pgtable.h would do the trick.


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

Re: [PATCH] mm: Define ARCH_HAS_FIRST_USER_ADDRESS

[Christophe Leroy]

Le 14/04/2021 à 04:54, Anshuman Khandual a écrit :

Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
for those platforms which would override generic default FIRST_USER_ADDRESS
value 0UL. This makes it much cleaner with reduced code.

Cc: linux-al...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-c...@vger.kernel.org
Cc: linux-hexa...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-m...@vger.kernel.org
Cc: openr...@lists.librecores.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-ri...@lists.infradead.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux...@lists.infradead.org
Cc: linux-xte...@linux-xtensa.org
Cc: x...@kernel.org
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
  arch/alpha/include/asm/pgtable.h | 1 -
  arch/arc/include/asm/pgtable.h   | 6 --
  arch/arm/Kconfig | 1 +
  arch/arm64/include/asm/pgtable.h | 2 --
  arch/csky/include/asm/pgtable.h  | 1 -
  arch/hexagon/include/asm/pgtable.h   | 3 ---
  arch/ia64/include/asm/pgtable.h  | 1 -
  arch/m68k/include/asm/pgtable_mm.h   | 1 -
  arch/microblaze/include/asm/pgtable.h| 2 --
  arch/mips/include/asm/pgtable-32.h   | 1 -
  arch/mips/include/asm/pgtable-64.h   | 1 -
  arch/nds32/Kconfig   | 1 +
  arch/nios2/include/asm/pgtable.h | 2 --
  arch/openrisc/include/asm/pgtable.h  | 1 -
  arch/parisc/include/asm/pgtable.h| 2 --
  arch/powerpc/include/asm/book3s/pgtable.h| 1 -
  arch/powerpc/include/asm/nohash/32/pgtable.h | 1 -
  arch/powerpc/include/asm/nohash/64/pgtable.h | 2 --
  arch/riscv/include/asm/pgtable.h | 2 --
  arch/s390/include/asm/pgtable.h  | 2 --
  arch/sh/include/asm/pgtable.h| 2 --
  arch/sparc/include/asm/pgtable_32.h  | 1 -
  arch/sparc/include/asm/pgtable_64.h  | 3 ---
  arch/um/include/asm/pgtable-2level.h | 1 -
  arch/um/include/asm/pgtable-3level.h | 1 -
  arch/x86/include/asm/pgtable_types.h | 2 --
  arch/xtensa/include/asm/pgtable.h| 1 -
  include/linux/mm.h   | 4 
  mm/Kconfig   | 4 
  29 files changed, 10 insertions(+), 43 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8ba434287387..47098ccd715e 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -46,6 +46,10 @@ extern int sysctl_page_lock_unfairness;
  
  void init_mm_internals(void);
  
+#ifndef ARCH_HAS_FIRST_USER_ADDRESS


I guess you didn't test it . :)

should be #ifndef CONFIG_ARCH_HAS_FIRST_USER_ADDRESS


+#define FIRST_USER_ADDRESS 0UL
+#endif


But why do we need a config option at all for that ?

Why not just:

#ifndef FIRST_USER_ADDRESS
#define FIRST_USER_ADDRESS  0UL
#endif


+
  #ifndef CONFIG_NEED_MULTIPLE_NODES/* Don't use mapnrs, do it properly */
  extern unsigned long max_mapnr;
  
diff --git a/mm/Kconfig b/mm/Kconfig

index 24c045b24b95..373fbe377075 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -806,6 +806,10 @@ config VMAP_PFN
  
  config ARCH_USES_HIGH_VMA_FLAGS

bool
+
+config ARCH_HAS_FIRST_USER_ADDRESS
+   bool
+
  config ARCH_HAS_PKEYS
bool
  



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

Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()

[Christophe Leroy]

Le 17/03/2021 à 02:52, Kefeng Wang a écrit :

mem_init_print_info() is called in mem_init() on each architecture,
and pass NULL argument, so using void argument and move it into mm_init().

Acked-by: Dave Hansen 
Signed-off-by: Kefeng Wang 
---
v2:
- Cleanup 'str' line suggested by Christophe and ACK

  arch/alpha/mm/init.c |  1 -
  arch/arc/mm/init.c   |  1 -
  arch/arm/mm/init.c   |  2 --
  arch/arm64/mm/init.c |  2 --
  arch/csky/mm/init.c  |  1 -
  arch/h8300/mm/init.c |  2 --
  arch/hexagon/mm/init.c   |  1 -
  arch/ia64/mm/init.c  |  1 -
  arch/m68k/mm/init.c  |  1 -
  arch/microblaze/mm/init.c|  1 -
  arch/mips/loongson64/numa.c  |  1 -
  arch/mips/mm/init.c  |  1 -
  arch/mips/sgi-ip27/ip27-memory.c |  1 -
  arch/nds32/mm/init.c |  1 -
  arch/nios2/mm/init.c |  1 -
  arch/openrisc/mm/init.c  |  2 --
  arch/parisc/mm/init.c|  2 --
  arch/powerpc/mm/mem.c|  1 -
  arch/riscv/mm/init.c |  1 -
  arch/s390/mm/init.c  |  2 --
  arch/sh/mm/init.c|  1 -
  arch/sparc/mm/init_32.c  |  2 --
  arch/sparc/mm/init_64.c  |  1 -
  arch/um/kernel/mem.c |  1 -
  arch/x86/mm/init_32.c|  2 --
  arch/x86/mm/init_64.c|  2 --
  arch/xtensa/mm/init.c|  1 -
  include/linux/mm.h   |  2 +-
  init/main.c  |  1 +
  mm/page_alloc.c  | 10 +-
  30 files changed, 7 insertions(+), 42 deletions(-)




diff --git a/include/linux/mm.h b/include/linux/mm.h
index 89314651dd62..c2e0b3495c5a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2373,7 +2373,7 @@ extern unsigned long free_reserved_area(void *start, void 
*end,
int poison, const char *s);
  
  extern void adjust_managed_page_count(struct page *page, long count);

-extern void mem_init_print_info(const char *str);
+extern void mem_init_print_info(void);


Sorry I didn't see that in previous patch.

'extern' keyword is pointless for function prototypes and is deprecated, you 
should remove it.

That said,

Reviewed-by: Christophe Leroy  # focussed on powerpc

  
  extern void reserve_bootmem_region(phys_addr_t start, phys_addr_t end);
  


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

Re: [PATCH RESEND] mm: Move mem_init_print_info() into mm_init()

[Christophe Leroy]

Le 16/03/2021 à 16:29, Kefeng Wang a écrit :

mem_init_print_info() is called in mem_init() on each architecture,
and pass NULL argument, so using void argument and move it into mm_init().

Signed-off-by: Kefeng Wang 
---

Resend with 'str' line cleanup, and only test on ARM64 qemu.

  arch/alpha/mm/init.c | 1 -
  arch/arc/mm/init.c   | 1 -
  arch/arm/mm/init.c   | 2 --
  arch/arm64/mm/init.c | 2 --
  arch/csky/mm/init.c  | 1 -
  arch/h8300/mm/init.c | 2 --
  arch/hexagon/mm/init.c   | 1 -
  arch/ia64/mm/init.c  | 1 -
  arch/m68k/mm/init.c  | 1 -
  arch/microblaze/mm/init.c| 1 -
  arch/mips/loongson64/numa.c  | 1 -
  arch/mips/mm/init.c  | 1 -
  arch/mips/sgi-ip27/ip27-memory.c | 1 -
  arch/nds32/mm/init.c | 1 -
  arch/nios2/mm/init.c | 1 -
  arch/openrisc/mm/init.c  | 2 --
  arch/parisc/mm/init.c| 2 --
  arch/powerpc/mm/mem.c| 1 -
  arch/riscv/mm/init.c | 1 -
  arch/s390/mm/init.c  | 2 --
  arch/sh/mm/init.c| 1 -
  arch/sparc/mm/init_32.c  | 2 --
  arch/sparc/mm/init_64.c  | 1 -
  arch/um/kernel/mem.c | 1 -
  arch/x86/mm/init_32.c| 2 --
  arch/x86/mm/init_64.c| 2 --
  arch/xtensa/mm/init.c| 1 -
  include/linux/mm.h   | 2 +-
  init/main.c  | 1 +
  mm/page_alloc.c  | 6 +++---
  30 files changed, 5 insertions(+), 40 deletions(-)




diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 55d938297ce6..cf5a2114c6d4 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7728,7 +7728,7 @@ unsigned long free_reserved_area(void *start, void *end, 
int poison, const char
return pages;
  }
  
-void __init mem_init_print_info(const char *str)

+void __init mem_init_print_info(void)
  {
unsigned long physpages, codesize, datasize, rosize, bss_size;
unsigned long init_code_size, init_data_size;
@@ -7767,7 +7767,7 @@ void __init mem_init_print_info(const char *str)
  #ifdefCONFIG_HIGHMEM
", %luK highmem"
  #endif
-   "%s%s)\n",
+   "%s)\n",
nr_free_pages() << (PAGE_SHIFT - 10),
physpages << (PAGE_SHIFT - 10),
codesize >> 10, datasize >> 10, rosize >> 10,
@@ -,7 +,7 @@ void __init mem_init_print_info(const char *str)
  #ifdefCONFIG_HIGHMEM
totalhigh_pages() << (PAGE_SHIFT - 10),
  #endif
-   str ? ", " : "", str ? str : "");
+   "");
  }
  
  /**




What is the benefit of a %s to print a constant "" ?

You should tidy up completely.

Christophe

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

Re: [PATCH] mm: Move mem_init_print_info() into mm_init()

[Christophe Leroy]

Le 16/03/2021 à 15:26, Kefeng Wang a écrit :

mem_init_print_info() is called in mem_init() on each architecture,
and pass NULL argument, cleanup it by using void argument and move
it into mm_init().

Signed-off-by: Kefeng Wang 
---
  arch/alpha/mm/init.c | 1 -
  arch/arc/mm/init.c   | 1 -
  arch/arm/mm/init.c   | 2 --
  arch/arm64/mm/init.c | 2 --
  arch/csky/mm/init.c  | 1 -
  arch/h8300/mm/init.c | 2 --
  arch/hexagon/mm/init.c   | 1 -
  arch/ia64/mm/init.c  | 1 -
  arch/m68k/mm/init.c  | 1 -
  arch/microblaze/mm/init.c| 1 -
  arch/mips/loongson64/numa.c  | 1 -
  arch/mips/mm/init.c  | 1 -
  arch/mips/sgi-ip27/ip27-memory.c | 1 -
  arch/nds32/mm/init.c | 1 -
  arch/nios2/mm/init.c | 1 -
  arch/openrisc/mm/init.c  | 2 --
  arch/parisc/mm/init.c| 2 --
  arch/powerpc/mm/mem.c| 1 -
  arch/riscv/mm/init.c | 1 -
  arch/s390/mm/init.c  | 2 --
  arch/sh/mm/init.c| 1 -
  arch/sparc/mm/init_32.c  | 2 --
  arch/sparc/mm/init_64.c  | 1 -
  arch/um/kernel/mem.c | 1 -
  arch/x86/mm/init_32.c| 2 --
  arch/x86/mm/init_64.c| 2 --
  arch/xtensa/mm/init.c| 1 -
  include/linux/mm.h   | 2 +-
  init/main.c  | 1 +
  mm/page_alloc.c  | 2 +-
  30 files changed, 3 insertions(+), 38 deletions(-)




diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 55d938297ce6..e4a6bf69c806 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7728,7 +7728,7 @@ unsigned long free_reserved_area(void *start, void *end, 
int poison, const char
return pages;
  }
  
-void __init mem_init_print_info(const char *str)

+void __init mem_init_print_info(void)
  {
unsigned long physpages, codesize, datasize, rosize, bss_size;
unsigned long init_code_size, init_data_size;



And what about the 'str' in the last line of the function ?

	pr_info("Memory: %luK/%luK available (%luK kernel code, %luK rwdata, %luK rodata, %luK init, %luK 
bss, %luK reserved, %luK cma-reserved"

#ifdef  CONFIG_HIGHMEM
", %luK highmem"
#endif
"%s%s)\n",
nr_free_pages() << (PAGE_SHIFT - 10),
physpages << (PAGE_SHIFT - 10),
codesize >> 10, datasize >> 10, rosize >> 10,
(init_data_size + init_code_size) >> 10, bss_size >> 10,
(physpages - totalram_pages() - totalcma_pages) << (PAGE_SHIFT 
- 10),
totalcma_pages << (PAGE_SHIFT - 10),
#ifdef  CONFIG_HIGHMEM
totalhigh_pages() << (PAGE_SHIFT - 10),
#endif
str ? ", " : "", str ? str : "");


Christophe

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

Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends

[Christophe Leroy]

There are also some users on 10+ year old 32-bit netbooks or
business laptops, both x86 and Apple G4.
The longest-lived 32-bit embedded systems with large memory
(other than Arm) are probably NXP QorIQ P20xx/P40xx used in
military VME bus systems, and low-end embedded systems based
on Vortex86.
I'm less worried about all of these because upstream kernel
support for ppc32 and x86-32 is already bitrotting and they will
likely get stuck on the last working kernel before the
TI/Renesas/NXP Arm systems do.



Upstream kernel support for ppc32 is bitrotting, seriously ? What do  
you mean exactly ?


ppc32 is actively supported, with recent addition of support of  
hugepages, kasan, uaccess protection, VMAP stack, etc ...


Christophe



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

Re: [PATCH v2 00/13] mm/debug_vm_pgtable fixes

[Christophe Leroy]

Le 21/08/2020 à 10:51, Anshuman Khandual a écrit :


On 08/19/2020 06:30 PM, Aneesh Kumar K.V wrote:

This patch series includes fixes for debug_vm_pgtable test code so that
they follow page table updates rules correctly. The first two patches introduce
changes w.r.t ppc64. The patches are included in this series for completeness. 
We can
merge them via ppc64 tree if required.

Hugetlb test is disabled on ppc64 because that needs larger change to satisfy
page table update rules.





Changes proposed here will impact other enabled platforms as well.
Adding the following folks and mailing lists, and hoping to get a
broader review and test coverage. Please do include them in the
next iteration as well.

+ linux-arm-ker...@lists.infradead.org
+ linux-s...@vger.kernel.org
+ linux-snps-arc@lists.infradead.org
+ x...@kernel.org
+ linux-a...@vger.kernel.org

+ Gerald Schaefer 
+ Christophe Leroy 


Please don't use anymore the above address. Only use the one below.


+ Christophe Leroy 
+ Vineet Gupta 
+ Mike Rapoport 
+ Qian Cai 



Thanks
Christophe

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

Re: [PATCH v3 12/13] mm/debug_vm_pgtable/hugetlb: Disable hugetlb test on ppc64

[Christophe Leroy]

Le 01/09/2020 à 08:30, Aneesh Kumar K.V a écrit :




I actually wanted to add #ifdef BROKEN. That test is completely broken. 
Infact I would suggest to remove that test completely.





#ifdef will not be required here as there would be a stub definition
for hugetlb_advanced_tests() when CONFIG_PPC_BOOK3S_64 is enabled.


  spin_lock(>page_table_lock);
  p4d_clear_tests(mm, p4dp);



But again, we should really try and avoid taking this path.



To be frank i am kind of frustrated with how this patch series is being 
looked at. We pushed a completely broken test to upstream and right now 
we have a code in upstream that crash when booted on ppc64. My attempt 
has been to make progress here and you definitely seems to be not in 
agreement to that.


At this point I am tempted to suggest we remove the DEBUG_VM_PGTABLE 
support on ppc64 because AFAIU it doesn't add any value.




Note that a bug has been filed at 
https://bugzilla.kernel.org/show_bug.cgi?id=209029


Christophe

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

Re: [PATCH v3 08/13] mm/debug_vm_pgtable/thp: Use page table depost/withdraw with THP

[Christophe Leroy]

Le 01/09/2020 à 09:40, Aneesh Kumar K.V a écrit :

On 9/1/20 12:20 PM, Christophe Leroy wrote:



Le 01/09/2020 à 08:25, Aneesh Kumar K.V a écrit :

On 9/1/20 8:52 AM, Anshuman Khandual wrote:




There is a checkpatch.pl warning here.

WARNING: Possible unwrapped commit description (prefer a maximum 75 
chars per line)

#7:
Architectures like ppc64 use deposited page table while updating the 
huge pte


total: 0 errors, 1 warnings, 40 lines checked



I will ignore all these, because they are not really important IMHO.



When doing a git log in a 80 chars terminal window, having wrapping 
lines is not really convenient. It should be easy to avoid it.




We have been ignoring that for a long time  isn't it?

For example ppc64 checkpatch already had
--max-line-length=90


There was also recent discussion whether 80 character limit is valid any 
more. But I do keep it restricted to 80 character where ever it is 
easy/make sense.




Here we are not talking about the code, but the commit log.

As far as I know, the discussions about 80 character lines, 90 lines in 
powerpc etc ... is for the code.


We still aim at keeping lines not longer than 75 chars in the commit log.

Christophe

Christophe

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

Re: [PATCH v3 08/13] mm/debug_vm_pgtable/thp: Use page table depost/withdraw with THP

[Christophe Leroy]

Le 01/09/2020 à 08:25, Aneesh Kumar K.V a écrit :

On 9/1/20 8:52 AM, Anshuman Khandual wrote:




There is a checkpatch.pl warning here.

WARNING: Possible unwrapped commit description (prefer a maximum 75 
chars per line)

#7:
Architectures like ppc64 use deposited page table while updating the 
huge pte


total: 0 errors, 1 warnings, 40 lines checked



I will ignore all these, because they are not really important IMHO.



When doing a git log in a 80 chars terminal window, having wrapping 
lines is not really convenient. It should be easy to avoid it.


Christophe

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

Re: [PATCH V3 0/4] mm/debug_vm_pgtable: Add some more tests

[Christophe Leroy]

Le 24/06/2020 à 05:13, Anshuman Khandual a écrit :



On 06/15/2020 09:07 AM, Anshuman Khandual wrote:

This series adds some more arch page table helper validation tests which
are related to core and advanced memory functions. This also creates a
documentation, enlisting expected semantics for all page table helpers as
suggested by Mike Rapoport previously (https://lkml.org/lkml/2020/1/30/40).

There are many TRANSPARENT_HUGEPAGE and ARCH_HAS_TRANSPARENT_HUGEPAGE_PUD
ifdefs scattered across the test. But consolidating all the fallback stubs
is not very straight forward because ARCH_HAS_TRANSPARENT_HUGEPAGE_PUD is
not explicitly dependent on ARCH_HAS_TRANSPARENT_HUGEPAGE.

Tested on arm64, x86 platforms but only build tested on all other enabled
platforms through ARCH_HAS_DEBUG_VM_PGTABLE i.e powerpc, arc, s390. The
following failure on arm64 still exists which was mentioned previously. It
will be fixed with the upcoming THP migration on arm64 enablement series.

WARNING  mm/debug_vm_pgtable.c:860 debug_vm_pgtable+0x940/0xa54
WARN_ON(!pmd_present(pmd_mkinvalid(pmd_mkhuge(pmd

This series is based on v5.8-rc1.

Changes in V3:

- Replaced HAVE_ARCH_SOFT_DIRTY with MEM_SOFT_DIRTY
- Added HAVE_ARCH_HUGE_VMAP checks in pxx_huge_tests() per Gerald
- Updated documentation for pmd_thp_tests() per Zi Yan
- Replaced READ_ONCE() with huge_ptep_get() per Gerald
- Added pte_mkhuge() and masking with PMD_MASK per Gerald
- Replaced pte_same() with holding pfn check in pxx_swap_tests()
- Added documentation for all (#ifdef #else #endif) per Gerald
- Updated pmd_protnone_tests() per Gerald
- Updated HugeTLB PTE creation in hugetlb_advanced_tests() per Gerald
- Replaced [pmd|pud]_mknotpresent() with [pmd|pud]_mkinvalid()
- Added has_transparent_hugepage() check for PMD and PUD tests
- Added a patch which debug prints all individual tests being executed
- Updated documentation for renamed [pmd|pud]_mkinvalid() helpers


Hello Gerald/Christophe/Vineet,

It would be really great if you could give this series a quick test
on s390/ppc/arc platforms respectively. Thank you.



Running ok on powerpc 8xx after fixing build failures.

Christophe

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

Re: [PATCH V3 2/4] mm/debug_vm_pgtable: Add tests validating advanced arch page table helpers

[Christophe Leroy]

Le 15/06/2020 à 05:37, Anshuman Khandual a écrit :

This adds new tests validating for these following arch advanced page table
helpers. These tests create and test specific mapping types at various page
table levels.

1. pxxp_set_wrprotect()
2. pxxp_get_and_clear()
3. pxxp_set_access_flags()
4. pxxp_get_and_clear_full()
5. pxxp_test_and_clear_young()
6. pxx_leaf()
7. pxx_set_huge()
8. pxx_(clear|mk)_savedwrite()
9. huge_pxxp_xxx()

Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Vineet Gupta 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Kirill A. Shutemov 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: x...@kernel.org
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Suggested-by: Catalin Marinas 
Signed-off-by: Anshuman Khandual 
---
  mm/debug_vm_pgtable.c | 306 ++
  1 file changed, 306 insertions(+)

diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index ffa163d4c63c..e3f9f8317a98 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -21,6 +21,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -28,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define VMFLAGS	(VM_READ|VM_WRITE|VM_EXEC)
  
@@ -55,6 +57,54 @@ static void __init pte_basic_tests(unsigned long pfn, pgprot_t prot)

WARN_ON(pte_write(pte_wrprotect(pte_mkwrite(pte;
  }
  
+static void __init pte_advanced_tests(struct mm_struct *mm,

+   struct vm_area_struct *vma, pte_t *ptep,
+   unsigned long pfn, unsigned long vaddr, pgprot_t prot)


Align args properly.


+{
+   pte_t pte = pfn_pte(pfn, prot);
+
+   pte = pfn_pte(pfn, prot);
+   set_pte_at(mm, vaddr, ptep, pte);
+   ptep_set_wrprotect(mm, vaddr, ptep);
+   pte = READ_ONCE(*ptep);
+   WARN_ON(pte_write(pte));
+
+   pte = pfn_pte(pfn, prot);
+   set_pte_at(mm, vaddr, ptep, pte);
+   ptep_get_and_clear(mm, vaddr, ptep);
+   pte = READ_ONCE(*ptep);
+   WARN_ON(!pte_none(pte));
+
+   pte = pfn_pte(pfn, prot);
+   pte = pte_wrprotect(pte);
+   pte = pte_mkclean(pte);
+   set_pte_at(mm, vaddr, ptep, pte);
+   pte = pte_mkwrite(pte);
+   pte = pte_mkdirty(pte);
+   ptep_set_access_flags(vma, vaddr, ptep, pte, 1);
+   pte = READ_ONCE(*ptep);
+   WARN_ON(!(pte_write(pte) && pte_dirty(pte)));
+
+   pte = pfn_pte(pfn, prot);
+   set_pte_at(mm, vaddr, ptep, pte);
+   ptep_get_and_clear_full(mm, vaddr, ptep, 1);
+   pte = READ_ONCE(*ptep);
+   WARN_ON(!pte_none(pte));
+
+   pte = pte_mkyoung(pte);
+   set_pte_at(mm, vaddr, ptep, pte);
+   ptep_test_and_clear_young(vma, vaddr, ptep);
+   pte = READ_ONCE(*ptep);
+   WARN_ON(pte_young(pte));
+}
+
+static void __init pte_savedwrite_tests(unsigned long pfn, pgprot_t prot)
+{
+   pte_t pte = pfn_pte(pfn, prot);
+
+   WARN_ON(!pte_savedwrite(pte_mk_savedwrite(pte_clear_savedwrite(pte;
+   WARN_ON(pte_savedwrite(pte_clear_savedwrite(pte_mk_savedwrite(pte;
+}
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
  static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot)
  {
@@ -77,6 +127,89 @@ static void __init pmd_basic_tests(unsigned long pfn, 
pgprot_t prot)
WARN_ON(!pmd_bad(pmd_mkhuge(pmd)));
  }
  
+static void __init pmd_advanced_tests(struct mm_struct *mm,

+   struct vm_area_struct *vma, pmd_t *pmdp,
+   unsigned long pfn, unsigned long vaddr, pgprot_t prot)


Align args properly


+{
+   pmd_t pmd = pfn_pmd(pfn, prot);
+
+   if (!has_transparent_hugepage())
+   return;
+
+   /* Align the address wrt HPAGE_PMD_SIZE */
+   vaddr = (vaddr & HPAGE_PMD_MASK) + HPAGE_PMD_SIZE;
+
+   pmd = pfn_pmd(pfn, prot);
+   set_pmd_at(mm, vaddr, pmdp, pmd);
+   pmdp_set_wrprotect(mm, vaddr, pmdp);
+   pmd = READ_ONCE(*pmdp);
+   WARN_ON(pmd_write(pmd));
+
+   pmd = pfn_pmd(pfn, prot);
+   set_pmd_at(mm, vaddr, pmdp, pmd);
+   pmdp_huge_get_and_clear(mm, vaddr, pmdp);
+   pmd = READ_ONCE(*pmdp);
+   WARN_ON(!pmd_none(pmd));
+
+   pmd = pfn_pmd(pfn, prot);
+   pmd = pmd_wrprotect(pmd);
+   pmd = pmd_mkclean(pmd);
+   set_pmd_at(mm, vaddr, pmdp, pmd);
+   pmd = pmd_mkwrite(pmd);
+   pmd = pmd_mkdirty(pmd);
+   pmdp_set_access_flags(vma, vaddr, pmdp, pmd, 1);
+   pmd = READ_ONCE(*pmdp);
+   WARN_ON(!(pmd_write(pmd) && pmd_dirty(pmd)));
+
+   pmd = pmd_mkhuge(pfn_pmd(pfn, prot));
+   set_pmd_at(mm, vaddr, pmdp, pmd);

Re: [PATCH V3 2/4] mm/debug_vm_pgtable: Add tests validating advanced arch page table helpers

[Christophe Leroy]

Le 15/06/2020 à 05:37, Anshuman Khandual a écrit :

This adds new tests validating for these following arch advanced page table
helpers. These tests create and test specific mapping types at various page
table levels.

1. pxxp_set_wrprotect()
2. pxxp_get_and_clear()
3. pxxp_set_access_flags()
4. pxxp_get_and_clear_full()
5. pxxp_test_and_clear_young()
6. pxx_leaf()
7. pxx_set_huge()
8. pxx_(clear|mk)_savedwrite()
9. huge_pxxp_xxx()

Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Vineet Gupta 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Kirill A. Shutemov 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: x...@kernel.org
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Suggested-by: Catalin Marinas 
Signed-off-by: Anshuman Khandual 
---
  mm/debug_vm_pgtable.c | 306 ++
  1 file changed, 306 insertions(+)

diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index ffa163d4c63c..e3f9f8317a98 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -21,6 +21,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -28,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define VMFLAGS	(VM_READ|VM_WRITE|VM_EXEC)
  
@@ -55,6 +57,54 @@ static void __init pte_basic_tests(unsigned long pfn, pgprot_t prot)

WARN_ON(pte_write(pte_wrprotect(pte_mkwrite(pte;
  }
  
+static void __init pte_advanced_tests(struct mm_struct *mm,

+   struct vm_area_struct *vma, pte_t *ptep,
+   unsigned long pfn, unsigned long vaddr, pgprot_t prot)
+{
+   pte_t pte = pfn_pte(pfn, prot);
+
+   pte = pfn_pte(pfn, prot);
+   set_pte_at(mm, vaddr, ptep, pte);
+   ptep_set_wrprotect(mm, vaddr, ptep);
+   pte = READ_ONCE(*ptep);


same


+   WARN_ON(pte_write(pte));
+
+   pte = pfn_pte(pfn, prot);
+   set_pte_at(mm, vaddr, ptep, pte);
+   ptep_get_and_clear(mm, vaddr, ptep);
+   pte = READ_ONCE(*ptep);


same


+   WARN_ON(!pte_none(pte));
+
+   pte = pfn_pte(pfn, prot);
+   pte = pte_wrprotect(pte);
+   pte = pte_mkclean(pte);
+   set_pte_at(mm, vaddr, ptep, pte);
+   pte = pte_mkwrite(pte);
+   pte = pte_mkdirty(pte);
+   ptep_set_access_flags(vma, vaddr, ptep, pte, 1);
+   pte = READ_ONCE(*ptep);


same


+   WARN_ON(!(pte_write(pte) && pte_dirty(pte)));
+
+   pte = pfn_pte(pfn, prot);
+   set_pte_at(mm, vaddr, ptep, pte);
+   ptep_get_and_clear_full(mm, vaddr, ptep, 1);
+   pte = READ_ONCE(*ptep);


same


+   WARN_ON(!pte_none(pte));
+
+   pte = pte_mkyoung(pte);
+   set_pte_at(mm, vaddr, ptep, pte);
+   ptep_test_and_clear_young(vma, vaddr, ptep);
+   pte = READ_ONCE(*ptep);


same


+   WARN_ON(pte_young(pte));
+}
+
+static void __init pte_savedwrite_tests(unsigned long pfn, pgprot_t prot)
+{
+   pte_t pte = pfn_pte(pfn, prot);
+
+   WARN_ON(!pte_savedwrite(pte_mk_savedwrite(pte_clear_savedwrite(pte;
+   WARN_ON(pte_savedwrite(pte_clear_savedwrite(pte_mk_savedwrite(pte;
+}
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
  static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot)
  {
@@ -77,6 +127,89 @@ static void __init pmd_basic_tests(unsigned long pfn, 
pgprot_t prot)
WARN_ON(!pmd_bad(pmd_mkhuge(pmd)));
  }
  
+static void __init pmd_advanced_tests(struct mm_struct *mm,

+   struct vm_area_struct *vma, pmd_t *pmdp,
+   unsigned long pfn, unsigned long vaddr, pgprot_t prot)
+{
+   pmd_t pmd = pfn_pmd(pfn, prot);
+
+   if (!has_transparent_hugepage())
+   return;
+
+   /* Align the address wrt HPAGE_PMD_SIZE */
+   vaddr = (vaddr & HPAGE_PMD_MASK) + HPAGE_PMD_SIZE;
+
+   pmd = pfn_pmd(pfn, prot);
+   set_pmd_at(mm, vaddr, pmdp, pmd);
+   pmdp_set_wrprotect(mm, vaddr, pmdp);
+   pmd = READ_ONCE(*pmdp);
+   WARN_ON(pmd_write(pmd));
+
+   pmd = pfn_pmd(pfn, prot);
+   set_pmd_at(mm, vaddr, pmdp, pmd);
+   pmdp_huge_get_and_clear(mm, vaddr, pmdp);
+   pmd = READ_ONCE(*pmdp);
+   WARN_ON(!pmd_none(pmd));
+
+   pmd = pfn_pmd(pfn, prot);
+   pmd = pmd_wrprotect(pmd);
+   pmd = pmd_mkclean(pmd);
+   set_pmd_at(mm, vaddr, pmdp, pmd);
+   pmd = pmd_mkwrite(pmd);
+   pmd = pmd_mkdirty(pmd);
+   pmdp_set_access_flags(vma, vaddr, pmdp, pmd, 1);
+   pmd = READ_ONCE(*pmdp);
+   WARN_ON(!(pmd_write(pmd) && pmd_dirty(pmd)));
+
+   pmd = pmd_mkhuge(pfn_pmd(pfn, prot));
+   set_pmd_at(mm, vaddr, pmdp, pmd);
+   

Re: [PATCH V2 0/3] mm/debug: Add more arch page table helper tests

[Christophe Leroy]

On 03/27/2020 06:46 AM, Anshuman Khandual wrote:


On 03/26/2020 08:53 PM, Christophe Leroy wrote:



Le 26/03/2020 à 03:23, Anshuman Khandual a écrit :



On 03/24/2020 10:52 AM, Anshuman Khandual wrote:

This series adds more arch page table helper tests. The new tests here are
either related to core memory functions and advanced arch pgtable helpers.
This also creates a documentation file enlisting all expected semantics as
suggested by Mike Rapoport (https://lkml.org/lkml/2020/1/30/40).

This series has been tested on arm64 and x86 platforms.


If folks can test these patches out on remaining ARCH_HAS_DEBUG_VM_PGTABLE
enabled platforms i.e s390, arc, powerpc (32 and 64), that will be really
appreciated. Thank you.



On powerpc 8xx (PPC32), I get:

[   53.338368] debug_vm_pgtable: debug_vm_pgtable: Validating architecture page 
table helpers
[   53.347403] [ cut here ]
[   53.351832] WARNING: CPU: 0 PID: 1 at mm/debug_vm_pgtable.c:647 
debug_vm_pgtable+0x280/0x3f4


mm/debug_vm_pgtable.c:647 ?

With the following commits in place

53a8338ce (HEAD) Documentation/mm: Add descriptions for arch page table helper
5d4913fc1 mm/debug: Add tests validating arch advanced page table helpers
bcaf120a7 mm/debug: Add tests validating arch page table helpers for core 
features
d6ed5a4a5 x86/memory: Drop pud_mknotpresent()
0739d1f8d mm/debug: Add tests validating architecture page table helpers
16fbf79b0 (tag: v5.6-rc7) Linux 5.6-rc7


I have:

facaa5eb5909 (HEAD -> helpers0) mm/debug: Add tests validating arch 
advanced page table helpers
6389fed515fc mm/debug: Add tests validating arch page table helpers for 
core features

dc14ecc8b94e mm/debug: add tests validating architecture page table helpers
c6624071c338 (origin/merge, merge) Automatic merge of branches 'master', 
'next' and 'fixes' into merge
58e05c5508e6 Automatic merge of branches 'master', 'next' and 'fixes' 
into merge
1b649e0bcae7 (origin/master, origin/HEAD) Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net


origin is https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git

I can't see your last patch in powerpc mailing list 
(https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=166237)




mm/debug_vm_pgtable.c:647 is here.


Line 647 is:

WARN_ON(!pte_same(pte, __swp_entry_to_pte(swp)));




#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
static void __init pmd_swap_tests(unsigned long pfn, pgprot_t prot)
{
 swp_entry_t swp;
 pmd_t pmd;  -> Line #647

 pmd = pfn_pmd(pfn, prot);
 swp = __pmd_to_swp_entry(pmd);
 WARN_ON(!pmd_same(pmd, __swp_entry_to_pmd(swp)));
}
#else
static void __init pmd_swap_tests(unsigned long pfn, pgprot_t prot) { }
#end

Did I miss something ?



[...]


Could you please point me to the exact test which is failing ?


[   53.519778] Freeing unused kernel memory: 608K



So I assume that the system should have come till runtime just fine apart from
the above warning message because.



Yes it boots fine otherwise.

Christophe

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

Re: [PATCH V2 0/3] mm/debug: Add more arch page table helper tests

[Christophe Leroy]

Le 26/03/2020 à 03:23, Anshuman Khandual a écrit :



On 03/24/2020 10:52 AM, Anshuman Khandual wrote:

This series adds more arch page table helper tests. The new tests here are
either related to core memory functions and advanced arch pgtable helpers.
This also creates a documentation file enlisting all expected semantics as
suggested by Mike Rapoport (https://lkml.org/lkml/2020/1/30/40).

This series has been tested on arm64 and x86 platforms.


If folks can test these patches out on remaining ARCH_HAS_DEBUG_VM_PGTABLE
enabled platforms i.e s390, arc, powerpc (32 and 64), that will be really
appreciated. Thank you.



On powerpc 8xx (PPC32), I get:

[   53.338368] debug_vm_pgtable: debug_vm_pgtable: Validating 
architecture page table helpers

[   53.347403] [ cut here ]
[   53.351832] WARNING: CPU: 0 PID: 1 at mm/debug_vm_pgtable.c:647 
debug_vm_pgtable+0x280/0x3f4
[   53.360140] CPU: 0 PID: 1 Comm: swapper Not tainted 
5.6.0-rc7-s3k-dev-01090-g92710e99881f #3544

[   53.368718] NIP:  c0777c04 LR: c0777bb8 CTR: 
[   53.373720] REGS: c9023df0 TRAP: 0700   Not tainted 
(5.6.0-rc7-s3k-dev-01090-g92710e99881f)

[   53.382042] MSR:  00029032   CR: 22000222  XER: 2000
[   53.388667]
[   53.388667] GPR00: c0777bb8 c9023ea8 c612 0001 1e41 
  007641c9
[   53.388667] GPR08:  0001   82000222 
 c00039b8 
[   53.388667] GPR16:    fff0 065fc000 
1e41 c660 01e4
[   53.388667] GPR24: 01d9 c062d14c c65fc000 c642d448 06c9 
 c65f8000 c65fc040

[   53.423400] NIP [c0777c04] debug_vm_pgtable+0x280/0x3f4
[   53.428559] LR [c0777bb8] debug_vm_pgtable+0x234/0x3f4
[   53.433593] Call Trace:
[   53.436048] [c9023ea8] [c0777bb8] debug_vm_pgtable+0x234/0x3f4 
(unreliable)

[   53.442936] [c9023f28] [c00039e0] kernel_init+0x28/0x124
[   53.448184] [c9023f38] [c000f174] ret_from_kernel_thread+0x14/0x1c
[   53.454245] Instruction dump:
[   53.457180] 41a20008 4bea3ed9 62890021 7d36b92e 7d36b82e 71290fd0 
3149 7d2a4910
[   53.464838] 0f09 5789077e 3149 7d2a4910 <0f09> 38c0 
38a0 3880

[   53.472671] ---[ end trace fd5dd92744dc0065 ]---
[   53.519778] Freeing unused kernel memory: 608K


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

Re: [PATCH V15] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 07/03/2020 à 01:56, Anshuman Khandual a écrit :



On 03/07/2020 06:04 AM, Qian Cai wrote:




On Mar 6, 2020, at 7:03 PM, Anshuman Khandual  wrote:

Hmm, set_pte_at() function is not preferred here for these tests. The idea
is to avoid or atleast minimize TLB/cache flushes triggered from these sort
of 'static' tests. set_pte_at() is platform provided and could/might trigger
these flushes or some other platform specific synchronization stuff. Just


Why is that important for this debugging option?


Primarily reason is to avoid TLB/cache flush instructions on the system
during these tests that only involve transforming different page table
level entries through helpers. Unless really necessary, why should it
emit any TLB/cache flush instructions ?


What's the problem with thoses flushes ?






wondering is there specific reason with respect to the soft lock up problem
making it necessary to use set_pte_at() rather than a simple WRITE_ONCE() ?


Looks at the s390 version of set_pte_at(), it has this comment,
vmaddr);

/*
  * Certain architectures need to do special things when PTEs
  * within a page table are directly modified.  Thus, the following
  * hook is made available.
  */

I can only guess that powerpc  could be the same here.


This comment is present in multiple platforms while defining set_pte_at().
Is not 'barrier()' here alone good enough ? Else what exactly set_pte_at()
does as compared to WRITE_ONCE() that avoids the soft lock up, just trying
to understand.




Argh ! I didn't realise that you were writing directly into the page 
tables. When it works, that's only by chance I guess.


To properly set the page table entries, set_pte_at() has to be used:
- On powerpc 8xx, with 16k pages, the page table entry must be copied 
four times. set_pte_at() does it, WRITE_ONCE() doesn't.
- On powerpc book3s/32 (hash MMU), the flag _PAGE_HASHPTE must be 
preserved among writes. set_pte_at() preserves it, WRITE_ONCE() doesn't.


set_pte_at() also does a few other mandatory things, like calling 
pte_mkpte()


So, the WRITE_ONCE() must definitely become a set_pte_at()

Christophe

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

Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 05/03/2020 à 01:54, Anshuman Khandual a écrit :



On 03/04/2020 04:59 PM, Qian Cai wrote:




On Mar 4, 2020, at 1:49 AM, Christophe Leroy  wrote:

AFAIU, you are not taking an interrupt here. You are stuck in the pte_update(), 
most likely due to nested locks. Try with LOCKDEP ?


Not exactly sure what did you mean here, but the kernel has all lockdep enabled 
and did not flag anything here.


As the patch has been dropped from Linux next (next-20200304) perhaps in
order to fold back the __pa_symbol() fix [1], so I am planning to respin
the original patch once more as V15 while adding Qian's signed off by for
the powerpc part. For now lets enable radix MMU ppc64 along with existing
ppc32. As PPC_RADIX_MMU depends on PPC_BOOK3S_64, the following change
should be good enough ?


I don't think so, even if you have the Radix MMU compiled in, hash MMU 
is used when Radix is not available or disabled. So until the Hash MMU 
problem is fixed, you cannot enable it by default.


Christophe

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

Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 04/03/2020 à 02:39, Qian Cai a écrit :



Below is slightly modified version of your change above and should still
prevent the bug on powerpc. Will it be possible for you to re-test this
? Once confirmed, will send a patch enabling this test on powerpc64
keeping your authorship. Thank you.


This works fine on radix MMU but I decided to go a bit future to test hash
MMU. The kernel will stuck here below. I did confirm that pte_alloc_map_lock()
was successful, so I don’t understand hash MMU well enough to tell why
it could still take an interrupt at pte_clear_tests() even before we calls
pte_unmap_unlock()?


AFAIU, you are not taking an interrupt here. You are stuck in the 
pte_update(), most likely due to nested locks. Try with LOCKDEP ?


Christophe



[   33.881515][T1] ok 8 - property-entry
[   33.883653][T1] debug_vm_pgtable: debug_vm_pgtable: Validating
architecture page table helpers
[   60.418885][C8] watchdog: BUG: soft lockup - CPU#8 stuck for 23s!
[swapper/0:1]



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

Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 02/03/2020 à 20:40, Qian Cai a écrit :

On Wed, 2020-02-26 at 10:51 -0500, Qian Cai wrote:

On Wed, 2020-02-26 at 15:45 +0100, Christophe Leroy wrote:


Le 26/02/2020 à 15:09, Qian Cai a écrit :

On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote:

This adds tests which will validate architecture page table helpers and
other accessors in their compliance with expected generic MM semantics.
This will help various architectures in validating changes to existing
page table helpers or addition of new ones.

This test covers basic page table entry transformations including but not
limited to old, young, dirty, clean, write, write protect etc at various
level along with populating intermediate entries with next page table page
and validating them.

Test page table pages are allocated from system memory with required size
and alignments. The mapped pfns at page table levels are derived from a
real pfn representing a valid kernel text symbol. This test gets called
inside kernel_init() right after async_synchronize_full().

This test gets built and run when CONFIG_DEBUG_VM_PGTABLE is selected. Any
architecture, which is willing to subscribe this test will need to select
ARCH_HAS_DEBUG_VM_PGTABLE. For now this is limited to arc, arm64, x86, s390
and ppc32 platforms where the test is known to build and run successfully.
Going forward, other architectures too can subscribe the test after fixing
any build or runtime problems with their page table helpers. Meanwhile for
better platform coverage, the test can also be enabled with CONFIG_EXPERT
even without ARCH_HAS_DEBUG_VM_PGTABLE.

Folks interested in making sure that a given platform's page table helpers
conform to expected generic MM semantics should enable the above config
which will just trigger this test during boot. Any non conformity here will
be reported as an warning which would need to be fixed. This test will help
catch any changes to the agreed upon semantics expected from generic MM and
enable platforms to accommodate it thereafter.


How useful is this that straightly crash the powerpc?

[   23.263425][T1] debug_vm_pgtable: debug_vm_pgtable: Validating
architecture page table helpers
[   23.263625][T1] [ cut here ]
[   23.263649][T1] kernel BUG at arch/powerpc/mm/pgtable.c:274!


The problem on PPC64 is known and has to be investigated and fixed.


It might be interesting to hear what powerpc64 maintainers would say about it
and if it is actually worth "fixing" in the arch code, but that BUG_ON() was
there since 2009 and had not been exposed until this patch comes alone?


This patch below makes it works on powerpc64 in order to dodge the BUG_ON()s in
assert_pte_locked() triggered by pte_clear_tests().


diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index 96dd7d574cef..50b385233971 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -55,6 +55,8 @@
  #define RANDOM_ORVALUEGENMASK(BITS_PER_LONG - 1, S390_MASK_BITS)
  #define RANDOM_NZVALUEGENMASK(7, 0)
  
+unsigned long vaddr;

+


Can we avoid global var ?


  static void __init pte_basic_tests(unsigned long pfn, pgprot_t prot)
  {
    pte_t pte = pfn_pte(pfn, prot);
@@ -256,7 +258,7 @@ static void __init pte_clear_tests(struct mm_struct *mm,
pte_t *ptep)
  
  	pte = __pte(pte_val(pte) | RANDOM_ORVALUE);

    WRITE_ONCE(*ptep, pte);
-   pte_clear(mm, 0, ptep);
+   pte_clear(mm, vaddr, ptep);
    pte = READ_ONCE(*ptep);
    WARN_ON(!pte_none(pte));
  }
@@ -310,8 +312,9 @@ void __init debug_vm_pgtable(void)
    pgtable_t saved_ptep;
    pgprot_t prot;
    phys_addr_t paddr;
-   unsigned long vaddr, pte_aligned, pmd_aligned;


Can we pass local vaddr to pte_clear_tests() instead of making it a 
global var ?



+   unsigned long pte_aligned, pmd_aligned;
    unsigned long pud_aligned, p4d_aligned, pgd_aligned;
+   spinlock_t *ptl;
  
  	pr_info("Validating architecture page table helpers\n");

    prot = vm_get_page_prot(VMFLAGS);
@@ -344,7 +347,7 @@ void __init debug_vm_pgtable(void)
    p4dp = p4d_alloc(mm, pgdp, vaddr);
    pudp = pud_alloc(mm, p4dp, vaddr);
    pmdp = pmd_alloc(mm, pudp, vaddr);
-   ptep = pte_alloc_map(mm, pmdp, vaddr);
+   ptep = pte_alloc_map_lock(mm, pmdp, vaddr, );
  
  	/*

     * Save all the page table page addresses as the page table
@@ -370,7 +373,7 @@ void __init debug_vm_pgtable(void)
    p4d_clear_tests(mm, p4dp);
    pgd_clear_tests(mm, pgdp);
  
-	pte_unmap(ptep);

+   pte_unmap_unlock(ptep, ptl);
  
  	pmd_populate_tests(mm, pmdp, saved_ptep);

    pud_populate_tests(mm, pudp, saved_pmdp);



Christophe

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

Re: [PATCH] mm/debug: Add tests validating arch page table helpers for core features

[Christophe Leroy]

Anshuman Khandual  a écrit :


On 02/27/2020 04:59 PM, Christophe Leroy wrote:



Le 27/02/2020 à 11:33, Anshuman Khandual a écrit :

This adds new tests validating arch page table helpers for these following
core memory features. These tests create and test specific mapping types at
various page table levels.

* SPECIAL mapping
* PROTNONE mapping
* DEVMAP mapping
* SOFTDIRTY mapping
* SWAP mapping
* MIGRATION mapping
* HUGETLB mapping
* THP mapping

Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Vineet Gupta 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Kirill A. Shutemov 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: x...@kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Suggested-by: Catalin Marinas 
Signed-off-by: Anshuman Khandual 
---
Tested on arm64 and x86 platforms without any test failures. But this has
only been built tested on several other platforms. Individual tests need
to be verified on all current enabling platforms for the test i.e s390,
ppc32, arc etc.

This patch must be applied on v5.6-rc3 after these patches

1. https://patchwork.kernel.org/patch/11385057/
2. https://patchwork.kernel.org/patch/11407715/

OR

This patch must be applied on linux-next (next-20200227) after this patch

2. https://patchwork.kernel.org/patch/11407715/

  mm/debug_vm_pgtable.c | 310 +-
  1 file changed, 309 insertions(+), 1 deletion(-)

diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index 96dd7d574cef..3fb90d5b604e 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -41,6 +41,44 @@
   * wrprotect(entry)    = A write protected and not a write entry
   * pxx_bad(entry)    = A mapped and non-table entry
   * pxx_same(entry1, entry2)    = Both entries hold the exact same value
+ *
+ * Specific feature operations
+ *
+ * pte_mkspecial(entry)    = Creates a special entry at PTE level
+ * pte_special(entry)    = Tests a special entry at PTE level
+ *
+ * pte_protnone(entry)    = Tests a no access entry at PTE level
+ * pmd_protnone(entry)    = Tests a no access entry at PMD level
+ *
+ * pte_mkdevmap(entry)    = Creates a device entry at PTE level
+ * pmd_mkdevmap(entry)    = Creates a device entry at PMD level
+ * pud_mkdevmap(entry)    = Creates a device entry at PUD level
+ * pte_devmap(entry)    = Tests a device entry at PTE level
+ * pmd_devmap(entry)    = Tests a device entry at PMD level
+ * pud_devmap(entry)    = Tests a device entry at PUD level
+ *
+ * pte_mksoft_dirty(entry)    = Creates a soft dirty entry at PTE level
+ * pmd_mksoft_dirty(entry)    = Creates a soft dirty entry at PMD level
+ * pte_swp_mksoft_dirty(entry)    = Creates a soft dirty swap  
entry at PTE level
+ * pmd_swp_mksoft_dirty(entry)    = Creates a soft dirty swap  
entry at PMD level

+ * pte_soft_dirty(entry)    = Tests a soft dirty entry at PTE level
+ * pmd_soft_dirty(entry)    = Tests a soft dirty entry at PMD level
+ * pte_swp_soft_dirty(entry)    = Tests a soft dirty swap entry  
at PTE level
+ * pmd_swp_soft_dirty(entry)    = Tests a soft dirty swap entry  
at PMD level
+ * pte_clear_soft_dirty(entry)   = Clears a soft dirty entry  
at PTE level
+ * pmd_clear_soft_dirty(entry)   = Clears a soft dirty entry  
at PMD level
+ * pte_swp_clear_soft_dirty(entry) = Clears a soft dirty swap  
entry at PTE level
+ * pmd_swp_clear_soft_dirty(entry) = Clears a soft dirty swap  
entry at PMD level

+ *
+ * pte_mkhuge(entry)    = Creates a HugeTLB entry at given level
+ * pte_huge(entry)    = Tests a HugeTLB entry at given level
+ *
+ * pmd_trans_huge(entry)    = Tests a trans huge page at PMD level
+ * pud_trans_huge(entry)    = Tests a trans huge page at PUD level
+ * pmd_present(entry)    = Tests an entry points to memory at  
PMD level
+ * pud_present(entry)    = Tests an entry points to memory at  
PUD level

+ * pmd_mknotpresent(entry)    = Invalidates an PMD entry for MMU
+ * pud_mknotpresent(entry)    = Invalidates an PUD entry for MMU
   */
  #define VMFLAGS    (VM_READ|VM_WRITE|VM_EXEC)
  @@ -287,6 +325,233 @@ static void __init  
pmd_populate_tests(struct mm_struct *mm, pmd_t *pmdp,

  WARN_ON(pmd_bad(pmd));
  }
  +#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL


Can we avoid ifdefs unless necessary ?

In mm/memory.c I see things like the following, it means  
pte_special() always exist and a #ifdef is not necessary.


True, #ifdef here can be dropped here, done.



if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) {
    if (likely(!pte_special(pte)))
    goto

Re: [PATCH] mm/debug: Add tests validating arch page table helpers for core features

[Christophe Leroy]

Le 27/02/2020 à 11:33, Anshuman Khandual a écrit :

This adds new tests validating arch page table helpers for these following
core memory features. These tests create and test specific mapping types at
various page table levels.

* SPECIAL mapping
* PROTNONE mapping
* DEVMAP mapping
* SOFTDIRTY mapping
* SWAP mapping
* MIGRATION mapping
* HUGETLB mapping
* THP mapping

Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Vineet Gupta 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Kirill A. Shutemov 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: x...@kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Suggested-by: Catalin Marinas 
Signed-off-by: Anshuman Khandual 
---
Tested on arm64 and x86 platforms without any test failures. But this has
only been built tested on several other platforms. Individual tests need
to be verified on all current enabling platforms for the test i.e s390,
ppc32, arc etc.

This patch must be applied on v5.6-rc3 after these patches

1. https://patchwork.kernel.org/patch/11385057/
2. https://patchwork.kernel.org/patch/11407715/

OR

This patch must be applied on linux-next (next-20200227) after this patch

2. https://patchwork.kernel.org/patch/11407715/

  mm/debug_vm_pgtable.c | 310 +-
  1 file changed, 309 insertions(+), 1 deletion(-)

diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index 96dd7d574cef..3fb90d5b604e 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -41,6 +41,44 @@
   * wrprotect(entry)   = A write protected and not a write entry
   * pxx_bad(entry) = A mapped and non-table entry
   * pxx_same(entry1, entry2)   = Both entries hold the exact same value
+ *
+ * Specific feature operations
+ *
+ * pte_mkspecial(entry)= Creates a special entry at PTE level
+ * pte_special(entry)  = Tests a special entry at PTE level
+ *
+ * pte_protnone(entry) = Tests a no access entry at PTE level
+ * pmd_protnone(entry) = Tests a no access entry at PMD level
+ *
+ * pte_mkdevmap(entry) = Creates a device entry at PTE level
+ * pmd_mkdevmap(entry) = Creates a device entry at PMD level
+ * pud_mkdevmap(entry) = Creates a device entry at PUD level
+ * pte_devmap(entry)   = Tests a device entry at PTE level
+ * pmd_devmap(entry)   = Tests a device entry at PMD level
+ * pud_devmap(entry)   = Tests a device entry at PUD level
+ *
+ * pte_mksoft_dirty(entry) = Creates a soft dirty entry at PTE level
+ * pmd_mksoft_dirty(entry) = Creates a soft dirty entry at PMD level
+ * pte_swp_mksoft_dirty(entry) = Creates a soft dirty swap entry at PTE level
+ * pmd_swp_mksoft_dirty(entry) = Creates a soft dirty swap entry at PMD level
+ * pte_soft_dirty(entry)   = Tests a soft dirty entry at PTE level
+ * pmd_soft_dirty(entry)   = Tests a soft dirty entry at PMD level
+ * pte_swp_soft_dirty(entry)   = Tests a soft dirty swap entry at PTE level
+ * pmd_swp_soft_dirty(entry)   = Tests a soft dirty swap entry at PMD level
+ * pte_clear_soft_dirty(entry)= Clears a soft dirty entry at PTE level
+ * pmd_clear_soft_dirty(entry)= Clears a soft dirty entry at PMD level
+ * pte_swp_clear_soft_dirty(entry) = Clears a soft dirty swap entry at PTE 
level
+ * pmd_swp_clear_soft_dirty(entry) = Clears a soft dirty swap entry at PMD 
level
+ *
+ * pte_mkhuge(entry)   = Creates a HugeTLB entry at given level
+ * pte_huge(entry) = Tests a HugeTLB entry at given level
+ *
+ * pmd_trans_huge(entry)   = Tests a trans huge page at PMD level
+ * pud_trans_huge(entry)   = Tests a trans huge page at PUD level
+ * pmd_present(entry)  = Tests an entry points to memory at PMD level
+ * pud_present(entry)  = Tests an entry points to memory at PUD level
+ * pmd_mknotpresent(entry) = Invalidates an PMD entry for MMU
+ * pud_mknotpresent(entry) = Invalidates an PUD entry for MMU
   */
  #define VMFLAGS   (VM_READ|VM_WRITE|VM_EXEC)
  
@@ -287,6 +325,233 @@ static void __init pmd_populate_tests(struct mm_struct *mm, pmd_t *pmdp,

WARN_ON(pmd_bad(pmd));
  }
  
+#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL


Can we avoid ifdefs unless necessary ?

In mm/memory.c I see things like the following, it means pte_special() 
always exist and a #ifdef is not necessary.


if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) {
if (likely(!pte_special(pte)))
goto check_pfn;
if (vma->vm_ops && vma->vm_ops->find_special_page)
  

Re: [PATCH] mm/debug: Add tests validating arch page table helpers for core features

[Christophe Leroy]

Le 27/02/2020 à 11:33, Anshuman Khandual a écrit :

This adds new tests validating arch page table helpers for these following
core memory features. These tests create and test specific mapping types at
various page table levels.

* SPECIAL mapping
* PROTNONE mapping
* DEVMAP mapping
* SOFTDIRTY mapping
* SWAP mapping
* MIGRATION mapping
* HUGETLB mapping


For testing HUGETLB mappings, you also have to include tests of hugepd 
functions/helpers. Not all archictures have hugepage size which matches 
with page tables levels (e.g. powerpc). Those architectures use hugepd_t.


Christophe

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

Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 26/02/2020 à 15:09, Qian Cai a écrit :

On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote:

This adds tests which will validate architecture page table helpers and
other accessors in their compliance with expected generic MM semantics.
This will help various architectures in validating changes to existing
page table helpers or addition of new ones.

This test covers basic page table entry transformations including but not
limited to old, young, dirty, clean, write, write protect etc at various
level along with populating intermediate entries with next page table page
and validating them.

Test page table pages are allocated from system memory with required size
and alignments. The mapped pfns at page table levels are derived from a
real pfn representing a valid kernel text symbol. This test gets called
inside kernel_init() right after async_synchronize_full().

This test gets built and run when CONFIG_DEBUG_VM_PGTABLE is selected. Any
architecture, which is willing to subscribe this test will need to select
ARCH_HAS_DEBUG_VM_PGTABLE. For now this is limited to arc, arm64, x86, s390
and ppc32 platforms where the test is known to build and run successfully.
Going forward, other architectures too can subscribe the test after fixing
any build or runtime problems with their page table helpers. Meanwhile for
better platform coverage, the test can also be enabled with CONFIG_EXPERT
even without ARCH_HAS_DEBUG_VM_PGTABLE.

Folks interested in making sure that a given platform's page table helpers
conform to expected generic MM semantics should enable the above config
which will just trigger this test during boot. Any non conformity here will
be reported as an warning which would need to be fixed. This test will help
catch any changes to the agreed upon semantics expected from generic MM and
enable platforms to accommodate it thereafter.


How useful is this that straightly crash the powerpc?

[   23.263425][T1] debug_vm_pgtable: debug_vm_pgtable: Validating
architecture page table helpers
[   23.263625][T1] [ cut here ]
[   23.263649][T1] kernel BUG at arch/powerpc/mm/pgtable.c:274!


The problem on PPC64 is known and has to be investigated and fixed.

Christophe

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

Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 26/02/2020 à 15:12, Qian Cai a écrit :

On Wed, 2020-02-26 at 09:09 -0500, Qian Cai wrote:

On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote:

How useful is this that straightly crash the powerpc?


And then generate warnings on arm64,

[  146.634626][T1] debug_vm_pgtable: debug_vm_pgtable: Validating
architecture page table helpers
[  146.643995][T1] [ cut here ]
[  146.649350][T1] virt_to_phys used for non-linear address:
(ptrval) (start_kernel+0x0/0x580)


Must be something wrong with the following in debug_vm_pgtable()

paddr = __pa(_kernel);

Is there any explaination why start_kernel() is not in linear memory on 
ARM64 ?


Christophe

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

Re: [PATCH V13] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 11/02/2020 à 03:25, Anshuman Khandual a écrit :



On 02/10/2020 04:36 PM, Russell King - ARM Linux admin wrote:

There are good reasons for the way ARM does stuff.  The generic crap was
written without regard for the circumstances that ARM has, and thus is
entirely unsuitable for 32-bit ARM.


Since we dont have an agreement here, lets just settle with disabling the
test for now on platforms where the build fails. CONFIG_EXPERT is enabling
this test for better adaptability and coverage, hence how about re framing
the config like this ? This at the least conveys the fact that EXPERT only
works when platform is neither IA64 or ARM.


Agreed



config DEBUG_VM_PGTABLE
bool "Debug arch page table for semantics compliance"
depends on MMU
depends on ARCH_HAS_DEBUG_VM_PGTABLE || (EXPERT &&  !(IA64 || ARM))


I think it's maybe better to have a dedicated depends line:

depends on !IA64 && !ARM
depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT

The day arm and/or ia64 is ready for building the test, we can remove 
that depends.



default n if !ARCH_HAS_DEBUG_VM_PGTABLE
default y if DEBUG_VM



Christophe

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

Re: [PATCH V13] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 10/02/2020 à 11:02, Russell King - ARM Linux admin a écrit :

On Mon, Feb 10, 2020 at 07:38:38AM +0100, Christophe Leroy wrote:



Le 10/02/2020 à 06:35, Anshuman Khandual a écrit :



On 02/10/2020 10:22 AM, Andrew Morton wrote:

On Thu, 6 Feb 2020 13:49:35 +0530 Anshuman Khandual  
wrote:



On 02/06/2020 04:40 AM, kbuild test robot wrote:

Hi Anshuman,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[also build test ERROR on s390/features linus/master arc/for-next v5.5]
[cannot apply to mmotm/master tip/x86/core arm64/for-next/core next-20200205]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug-Add-tests-validating-architecture-page-table-helpers/20200205-215507
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.5.0
reproduce:
  wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
  chmod +x ~/bin/make.cross
  # save the attached .config to linux build tree
  GCC_VERSION=7.5.0 make.cross ARCH=ia64

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All error/warnings (new ones prefixed by >>):

 In file included from include/asm-generic/pgtable-nopud.h:8:0,
  from arch/ia64/include/asm/pgtable.h:586,
  from include/linux/mm.h:99,
  from include/linux/highmem.h:8,
  from mm/debug_vm_pgtable.c:14:
 mm/debug_vm_pgtable.c: In function 'pud_clear_tests':

include/asm-generic/pgtable-nop4d-hack.h:47:32: error: implicit declaration of 
function '__pgd'; did you mean '__p4d'? [-Werror=implicit-function-declaration]

  #define __pud(x)((pud_t) { __pgd(x) })
 ^

mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'

   pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
 ^

include/asm-generic/pgtable-nop4d-hack.h:47:22: warning: missing braces around 
initializer [-Wmissing-braces]

  #define __pud(x)((pud_t) { __pgd(x) })
   ^

mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'

   pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
 ^
 cc1: some warnings being treated as errors


This build failure is expected now given that we have allowed DEBUG_VM_PGTABLE
with EXPERT without platform requiring ARCH_HAS_DEBUG_VM_PGTABLE. This problem
i.e build failure caused without a platform __pgd(), is known to exist both on
ia64 and arm (32bit) platforms. Please refer https://lkml.org/lkml/2019/9/24/314
for details where this was discussed earlier.



I'd prefer not to merge a patch which is known to cause build
regressions.  Is there some temporary thing we can do to prevent these
errors until arch maintainers(?) get around to implementing the
long-term fixes?


We could explicitly disable CONFIG_DEBUG_VM_PGTABLE on ia64 and arm platforms
which will ensure that others can still use the EXPERT path.

config DEBUG_VM_PGTABLE
bool "Debug arch page table for semantics compliance"
depends on MMU
depends on !(IA64 || ARM)
depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
default n if !ARCH_HAS_DEBUG_VM_PGTABLE
default y if DEBUG_VM



On both ia32 and arm, the fix is trivial.

Can we include the fix within this patch, just the same way as the
mm_p4d_folded() fix for x86 ?


Why should arm include a macro for something that nothing (apart from
this checker) requires?  If the checker requires it but the rest of
the kernel does not, it suggests that the checker isn't actually
correct, and the results can't be relied upon.



As far as I can see, the problem is that arm opencodes part of the API 
instead of including asm-generic/pgtable-nopmd.h


Here, the ARM has 2 levels, ie only PGD and PTE. But instead of defining 
__pgd and __pte and getting everything else from asm-generic, it defines 
a __pmd then redefines the folded levels like the pud, etc ...


That's exactly what the checker aims at detecting: architectures than do 
not properly use the standard linux page table structures.


Christophe

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

Re: [PATCH V13] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 10/02/2020 à 06:35, Anshuman Khandual a écrit :



On 02/10/2020 10:22 AM, Andrew Morton wrote:

On Thu, 6 Feb 2020 13:49:35 +0530 Anshuman Khandual  
wrote:



On 02/06/2020 04:40 AM, kbuild test robot wrote:

Hi Anshuman,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[also build test ERROR on s390/features linus/master arc/for-next v5.5]
[cannot apply to mmotm/master tip/x86/core arm64/for-next/core next-20200205]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug-Add-tests-validating-architecture-page-table-helpers/20200205-215507
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.5.0
reproduce:
 wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # save the attached .config to linux build tree
 GCC_VERSION=7.5.0 make.cross ARCH=ia64

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All error/warnings (new ones prefixed by >>):

In file included from include/asm-generic/pgtable-nopud.h:8:0,
 from arch/ia64/include/asm/pgtable.h:586,
 from include/linux/mm.h:99,
 from include/linux/highmem.h:8,
 from mm/debug_vm_pgtable.c:14:
mm/debug_vm_pgtable.c: In function 'pud_clear_tests':

include/asm-generic/pgtable-nop4d-hack.h:47:32: error: implicit declaration of 
function '__pgd'; did you mean '__p4d'? [-Werror=implicit-function-declaration]

 #define __pud(x)((pud_t) { __pgd(x) })
^

mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'

  pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
^

include/asm-generic/pgtable-nop4d-hack.h:47:22: warning: missing braces around 
initializer [-Wmissing-braces]

 #define __pud(x)((pud_t) { __pgd(x) })
  ^

mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'

  pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
^
cc1: some warnings being treated as errors


This build failure is expected now given that we have allowed DEBUG_VM_PGTABLE
with EXPERT without platform requiring ARCH_HAS_DEBUG_VM_PGTABLE. This problem
i.e build failure caused without a platform __pgd(), is known to exist both on
ia64 and arm (32bit) platforms. Please refer https://lkml.org/lkml/2019/9/24/314
for details where this was discussed earlier.



I'd prefer not to merge a patch which is known to cause build
regressions.  Is there some temporary thing we can do to prevent these
errors until arch maintainers(?) get around to implementing the
long-term fixes?


We could explicitly disable CONFIG_DEBUG_VM_PGTABLE on ia64 and arm platforms
which will ensure that others can still use the EXPERT path.

config DEBUG_VM_PGTABLE
bool "Debug arch page table for semantics compliance"
depends on MMU
depends on !(IA64 || ARM)
depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
default n if !ARCH_HAS_DEBUG_VM_PGTABLE
default y if DEBUG_VM



On both ia32 and arm, the fix is trivial.

Can we include the fix within this patch, just the same way as the 
mm_p4d_folded() fix for x86 ?


Christophe

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

Re: [PATCH V12] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 02/02/2020 à 12:26, Qian Cai a écrit :




On Jan 30, 2020, at 9:13 AM, Christophe Leroy  wrote:

config DEBUG_VM_PGTABLE
bool "Debug arch page table for semantics compliance" if 
ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
depends on MMU
default 'n' if !ARCH_HAS_DEBUG_VM_PGTABLE
default 'y' if DEBUG_VM


Does it really necessary to potentially force all bots to run this? Syzbot, 
kernel test robot etc? Does it ever pay off for all their machine times there?



Machine time ?

On a 32 bits powerpc running at 132 MHz, the tests takes less than 10ms. 
Is it worth taking the risk of not detecting faults by not selecting it 
by default ?


[5.656916] debug_vm_pgtable: debug_vm_pgtable: Validating 
architecture page table helpers
[5.665661] debug_vm_pgtable: debug_vm_pgtable: Validated 
architecture page table helpers


Christophe

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

Re: [PATCH V12] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 02/02/2020 à 08:18, Anshuman Khandual a écrit :

On 01/30/2020 07:43 PM, Christophe Leroy wrote:



Le 30/01/2020 à 14:04, Anshuman Khandual a écrit :


On 01/28/2020 10:35 PM, Christophe Leroy wrote:





I think we could make it standalone and 'default y if DEBUG_VM' instead.


Which will yield the same result like before but in a different way. But
yes, this test could go about either way but unless there is a good enough
reason why change the current one.


I think if we want people to really use it on other architectures it must be 
possible to activate it without having to modify Kconfig. Otherwise people 
won't even know the test exists and the architecture fails the test.

The purpose of a test suite is to detect bugs. If you can't run the test until 
you have fixed the bugs, I guess nobody will ever detect the bugs and they will 
never be fixed.

So I think:
- the test should be 'default y' when ARCH_HAS_DEBUG_VM_PGTABLE is selected
- the test should be 'default n' when ARCH_HAS_DEBUG_VM_PGTABLE is not 
selected, and it should be user selectable if EXPERT is selected.

Something like:

config DEBUG_VM_PGTABLE
     bool "Debug arch page table for semantics compliance" if 
ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
     depends on MMU


(ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT) be moved along side MMU on the same line ?


Yes could also go along side MMU, or could be a depend by itself:
depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT




     default 'n' if !ARCH_HAS_DEBUG_VM_PGTABLE
     default 'y' if DEBUG_VM


This looks good, at least until we get all platforms enabled. Will do all these
changes along with s390 enablement and re-spin.


Christophe

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

Re: [PATCH V12] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 30/01/2020 à 14:04, Anshuman Khandual a écrit :


On 01/28/2020 10:35 PM, Christophe Leroy wrote:



Le 28/01/2020 à 02:27, Anshuman Khandual a écrit :

diff --git a/arch/x86/include/asm/pgtable_64.h 
b/arch/x86/include/asm/pgtable_64.h
index 0b6c4042942a..fb0e76d254b3 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -53,6 +53,12 @@ static inline void sync_initial_page_table(void) { }
     struct mm_struct;
   +#define mm_p4d_folded mm_p4d_folded
+static inline bool mm_p4d_folded(struct mm_struct *mm)
+{
+    return !pgtable_l5_enabled();
+}
+


For me this should be part of another patch, it is not directly linked to the 
tests.


We did discuss about this earlier and Kirril mentioned its not worth
a separate patch.

https://lore.kernel.org/linux-arm-kernel/20190913091305.rkds4f3fqv3yjhjy@box/


For me it would make sense to not mix this patch which implement tests, 
and changes that are needed for the test to work (or even build) on the 
different architectures.


But that's up to you.






   void set_pte_vaddr_p4d(p4d_t *p4d_page, unsigned long vaddr, pte_t new_pte);
   void set_pte_vaddr_pud(pud_t *pud_page, unsigned long vaddr, pte_t new_pte);
   diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 798ea36a0549..e0b04787e789 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -1208,6 +1208,12 @@ static inline bool arch_has_pfn_modify_check(void)
   # define PAGE_KERNEL_EXEC PAGE_KERNEL
   #endif
   +#ifdef CONFIG_DEBUG_VM_PGTABLE


Not sure it is a good idea to put that in include/asm-generic/pgtable.h


Logically that is the right place, as it is related to page table but
not something platform related.


I can't see any debug related features in that file.





By doing this you are forcing a rebuild of almost all files, whereas only 
init/main.o and mm/debug_vm_pgtable.o should be rebuilt when activating this 
config option.


I agreed but whats the alternative ? We could move these into init/main.c
to make things simpler but will that be a right place, given its related
to generic page table.


What about linux/mmdebug.h instead ? (I have not checked if it would 
reduce the impact, but that's where things related to CONFIG_DEBUG_VM 
seems to be).


Otherwise, you can just create new file, for instance 
 and include that file only in the init/main.c 
and mm/debug_vm_pgtable.c









+extern void debug_vm_pgtable(void);


Please don't use the 'extern' keyword, it is useless and not to be used for 
functions declaration.


Really ? But, there are tons of examples doing the same thing both in
generic and platform code as well.


Yes, but how can we improve if we blindly copy the errors from the past 
? Having tons of 'extern' doesn't mean we must add more.


I think checkpatch.pl usually complains when a patch brings a new 
unreleval extern symbol.







+#else
+static inline void debug_vm_pgtable(void) { }
+#endif
+
   #endif /* !__ASSEMBLY__ */
     #ifndef io_remap_pfn_range
diff --git a/init/main.c b/init/main.c
index da1bc0b60a7d..5e59e6ac0780 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1197,6 +1197,7 @@ static noinline void __init kernel_init_freeable(void)
   sched_init_smp();
     page_alloc_init_late();
+    debug_vm_pgtable();


Wouldn't it be better to call debug_vm_pgtable() in kernel_init() between the 
call to async_synchronise_full() and ftrace_free_init_mem() ?


IIRC, proposed location is the earliest we could call debug_vm_pgtable().
Is there any particular benefit or reason to move it into kernel_init() ?


It would avoid having it lost in the middle of drivers logs, would be 
close to the end of init, at a place we can't miss it, close to the 
result of other tests like CONFIG_DEBUG_RODATA_TEST for instance.


At the moment, you have to look for it to be sure the test is done and 
what the result is.







   /* Initialize page ext after all struct pages are initialized. */
   page_ext_init();
   diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 5ffe144c9794..7cceae923c05 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -653,6 +653,12 @@ config SCHED_STACK_END_CHECK
     data corruption or a sporadic crash at a later stage once the region
     is examined. The runtime overhead introduced is minimal.
   +config ARCH_HAS_DEBUG_VM_PGTABLE
+    bool
+    help
+  An architecture should select this when it can successfully
+  build and run DEBUG_VM_PGTABLE.
+
   config DEBUG_VM
   bool "Debug VM"
   depends on DEBUG_KERNEL
@@ -688,6 +694,22 @@ config DEBUG_VM_PGFLAGS
       If unsure, say N.
   +config DEBUG_VM_PGTABLE
+    bool "Debug arch page table for semantics compliance"
+    depends on MMU
+    depends on DEBUG_VM


Does it really need to depend on DEBUG_VM ?


No. It seemed better to package this test along with DEBUG_VM (although I
dont remember the conversation around it) and hence th

Re: [PATCH V12] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 28/01/2020 à 06:48, Qian Cai a écrit :




On Jan 27, 2020, at 11:58 PM, Anshuman Khandual  
wrote:

As I had mentioned before, the test attempts to formalize page table helper 
semantics
as expected from generic MM code paths and intend to catch deviations when 
enabled on
a given platform. How else should we test semantics errors otherwise ? There 
are past
examples of usefulness for this procedure on arm64 and on s390. I am wondering 
how
else to prove the usefulness of a debug feature if these references are not 
enough.


Not saying it will not be useful. As you mentioned it actually found a bug or 
two in the past. The problem is that there is always a cost to maintain 
something like this, and nobody knew how things could be broken even for the 
isolated code you mentioned in the future given how complicated the kernel code 
base is. I am not so positive that many developers would enable this debug 
feature and use it on a regular basis from the information you gave so far.

On the other hand, it might just be good at maintaining this thing out of tree 
by yourself anyway, because if there isn’t going to be used by many developers, 
few people is going to contribute to this and even noticed when it is broken. 
What’s the point of getting this merged apart from being getting some 
meaningless credits?



It is 'default y' so there is no much risk that it is forgotten, at 
least all test suites run with 'allyes_defconfig' will trigger the test, 
so I think it is really a good feature.


Christophe

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

Re: [PATCH V12] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 28/01/2020 à 04:33, Qian Cai a écrit :




On Jan 27, 2020, at 10:06 PM, Anshuman Khandual  
wrote:



On 01/28/2020 07:41 AM, Qian Cai wrote:




On Jan 27, 2020, at 8:28 PM, Anshuman Khandual  
wrote:

This adds tests which will validate architecture page table helpers and
other accessors in their compliance with expected generic MM semantics.
This will help various architectures in validating changes to existing
page table helpers or addition of new ones.

This test covers basic page table entry transformations including but not
limited to old, young, dirty, clean, write, write protect etc at various
level along with populating intermediate entries with next page table page
and validating them.

Test page table pages are allocated from system memory with required size
and alignments. The mapped pfns at page table levels are derived from a
real pfn representing a valid kernel text symbol. This test gets called
right after page_alloc_init_late().

This gets build and run when CONFIG_DEBUG_VM_PGTABLE is selected along with
CONFIG_VM_DEBUG. Architectures willing to subscribe this test also need to
select CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE which for now is limited to x86 and
arm64. Going forward, other architectures too can enable this after fixing
build or runtime problems (if any) with their page table helpers.


Hello Qian,



What’s the value of this block of new code? It only supports x86 and arm64
which are supposed to be good now.


We have been over the usefulness of this code many times before as the patch is
already in it's V12. Currently it is enabled on arm64, x86 (except PAE), arc and
ppc32. There are build time or runtime problems with other archs which prevent


I am not sure if I care too much about arc and ppc32 which are pretty much 
legacy
platforms.


enablement of this test (for the moment) but then the goal is to integrate all
of them going forward. The test not only validates platform's adherence to the
expected semantics from generic MM but also helps in keeping it that way during
code changes in future as well.


Another option maybe to get some decent arches on board first before merging 
this
thing, so it have more changes to catch regressions for developers who might 
run this.



ppc32 an indecent / legacy platform ? Are you kidying ?

Powerquicc II PRO for instance is fully supported by the manufacturer 
and widely used in many small networking devices.


Christophe

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

Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument

[Christophe Leroy]

Hi Geert,

Le 08/01/2020 à 09:43, Geert Uytterhoeven a écrit :

Hi Christophe,

On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy  wrote:

Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :

On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven  wrote:

On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven  wrote:

On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski  wrote:

The ioread8/16/32() and others have inconsistent interface among the
architectures: some taking address as const, some not.

It seems there is nothing really stopping all of them to take
pointer to const.


Shouldn't all of them take const volatile __iomem pointers?
It seems the "volatile" is missing from all but the implementations in
include/asm-generic/io.h.


As my "volatile" comment applies to iowrite*(), too, probably that should be
done in a separate patch.

Hence with patches 1-5 squashed, and for patches 11-13:
Reviewed-by: Geert Uytterhoeven 


I'll add to this one also changes to ioreadX_rep() and add another
patch for volatile for reads and writes. I guess your review will be
appreciated once more because of ioreadX_rep()


volatile should really only be used where deemed necessary:

https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html

It is said: " ...  accessor functions might use volatile on
architectures where direct I/O memory access does work. Essentially,
each accessor call becomes a little critical section on its own and
ensures that the access happens as expected by the programmer."


That is exactly the use case here: all above are accessor functions.

Why would ioreadX() not need volatile, while readY() does?



My point was: it might be necessary for some arches and not for others.

And as pointed by Arnd, the volatile is really only necessary for the 
dereference itself, should the arch use dereferencing.


So I guess the best would be to go in the other direction: remove 
volatile keyword wherever possible instead of adding it where it is not 
needed.


Christophe

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

Re: [PATCH V8] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 06/11/2019 à 04:22, Anshuman Khandual a écrit :



On 10/28/2019 10:59 AM, Anshuman Khandual wrote:

+---
+| arch |status|
+---
+|   alpha: | TODO |
+| arc: | TODO |
+| arm: | TODO |
+|   arm64: |  ok  |
+| c6x: | TODO |
+|csky: | TODO |
+|   h8300: | TODO |
+| hexagon: | TODO |
+|ia64: | TODO |
+|m68k: | TODO |
+|  microblaze: | TODO |
+|mips: | TODO |
+|   nds32: | TODO |
+|   nios2: | TODO |
+|openrisc: | TODO |
+|  parisc: | TODO |
+| powerpc: | TODO |
+|   ppc32: |  ok  |


Note that ppc32 is a part of powerpc, not a standalone arch.

Maybe something like the following would be more correct:
|  powerpc/32: |  ok  |
|  powerpc/64: | TODO |

Christophe


+|   riscv: | TODO |
+|s390: | TODO |
+|  sh: | TODO |
+|   sparc: | TODO |
+|  um: | TODO |
+|   unicore32: | TODO |
+| x86: |  ok  |
+|  xtensa: | TODO |
+---


While here, are there some volunteers to test this on any of the
'yet to be tested and supported' platforms ?

- Anshuman



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

Re: [PATCH V7] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

Le 25/10/2019 à 10:24, Anshuman Khandual a écrit :



On 10/25/2019 12:41 PM, Christophe Leroy wrote:



Le 25/10/2019 à 07:52, Qian Cai a écrit :




On Oct 24, 2019, at 11:45 PM, Anshuman Khandual  
wrote:

Nothing specific. But just tested this with x86 defconfig with relevant configs
which are required for this test. Not sure if it involved W=1.


No, it will not. It needs to run like,

make W=1 -j 64 2>/tmp/warns



Are we talking about this peace of code ?

+static unsigned long __init get_random_vaddr(void)
+{
+    unsigned long random_vaddr, random_pages, total_user_pages;
+
+    total_user_pages = (TASK_SIZE - FIRST_USER_ADDRESS) / PAGE_SIZE;
+
+    random_pages = get_random_long() % total_user_pages;
+    random_vaddr = FIRST_USER_ADDRESS + random_pages * PAGE_SIZE;
+
+    WARN_ON((random_vaddr > TASK_SIZE) ||
+    (random_vaddr < FIRST_USER_ADDRESS));
+    return random_vaddr;
+}
+

ramdom_vaddr is unsigned,
random_pages is unsigned and lower than total_user_pages

So the max value random_vaddr can get is FIRST_USER_ADDRESS + ((TASK_SIZE - 
FIRST_USER_ADDRESS - 1) / PAGE_SIZE) * PAGE_SIZE = TASK_SIZE - 1
And the min value random_vaddr can get is FIRST_USER_ADDRESS (that's when 
random_pages = 0)


That's right.



So the WARN_ON() is just unneeded, isn't it ?


It is just a sanity check on possible vaddr values before it's corresponding
page table mappings could be created. If it's worth to drop this in favor of
avoiding these unwanted warning messages on x86, will go ahead with it as it
is not super important.



But you are checking what ? That the compiler does calculation correctly 
or what ?
As mentionned just above, based on the calculation done, what you are 
testing cannot happen, so I'm having a hard time understanding what kind 
of sanity check it can be.


Can you give an exemple of a situation which could trigger the warning ?

Christophe

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

Re: [PATCH V7] mm/debug: Add tests validating architecture page table helpers

[Christophe Leroy]

On 10/21/2019 02:42 AM, Anshuman Khandual wrote:

This adds tests which will validate architecture page table helpers and
other accessors in their compliance with expected generic MM semantics.
This will help various architectures in validating changes to existing
page table helpers or addition of new ones.

This test covers basic page table entry transformations including but not
limited to old, young, dirty, clean, write, write protect etc at various
level along with populating intermediate entries with next page table page
and validating them.

Test page table pages are allocated from system memory with required size
and alignments. The mapped pfns at page table levels are derived from a
real pfn representing a valid kernel text symbol. This test gets called
right after page_alloc_init_late().

This gets build and run when CONFIG_DEBUG_VM_PGTABLE is selected along with
CONFIG_VM_DEBUG. Architectures willing to subscribe this test also need to
select CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE which for now is limited to x86 and
arm64. Going forward, other architectures too can enable this after fixing
build or runtime problems (if any) with their page table helpers.

Folks interested in making sure that a given platform's page table helpers
conform to expected generic MM semantics should enable the above config
which will just trigger this test during boot. Any non conformity here will
be reported as an warning which would need to be fixed. This test will help
catch any changes to the agreed upon semantics expected from generic MM and
enable platforms to accommodate it thereafter.

Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Greg Kroah-Hartman 
Cc: Thomas Gleixner 
Cc: Mike Rapoport 
Cc: Jason Gunthorpe 
Cc: Dan Williams 
Cc: Peter Zijlstra 
Cc: Michal Hocko 
Cc: Mark Rutland 
Cc: Mark Brown 
Cc: Steven Price 
Cc: Ard Biesheuvel 
Cc: Masahiro Yamada 
Cc: Kees Cook 
Cc: Tetsuo Handa 
Cc: Matthew Wilcox 
Cc: Sri Krishna chowdary 
Cc: Dave Hansen 
Cc: Russell King - ARM Linux 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: "David S. Miller" 
Cc: Vineet Gupta 
Cc: James Hogan 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Kirill A. Shutemov 
Cc: Gerald Schaefer 
Cc: Christophe Leroy 
Cc: Ingo Molnar 
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-ker...@vger.kernel.org

Tested-by: Christophe Leroy  #PPC32
Suggested-by: Catalin Marinas 
Signed-off-by: Andrew Morton 
Signed-off-by: Christophe Leroy 
Signed-off-by: Anshuman Khandual 
---


The cover letter have the exact same title as this patch. I think a 
cover letter is not necessary for a singleton series.


The history (and any other information you don't want to include in the 
commit message) can be added here, below the '---'. That way it is in 
the mail but won't be included in the commit.



  .../debug/debug-vm-pgtable/arch-support.txt|  34 ++
  arch/arm64/Kconfig |   1 +
  arch/x86/Kconfig   |   1 +
  arch/x86/include/asm/pgtable_64.h  |   6 +
  include/asm-generic/pgtable.h  |   6 +
  init/main.c|   1 +
  lib/Kconfig.debug  |  21 ++
  mm/Makefile|   1 +
  mm/debug_vm_pgtable.c  | 388 +
  9 files changed, 459 insertions(+)
  create mode 100644 
Documentation/features/debug/debug-vm-pgtable/arch-support.txt
  create mode 100644 mm/debug_vm_pgtable.c

diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt 
b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
new file mode 100644
index 000..d6b8185
--- /dev/null
+++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
@@ -0,0 +1,34 @@
+#
+# Feature name:  debug-vm-pgtable
+# Kconfig:   ARCH_HAS_DEBUG_VM_PGTABLE
+# description:   arch supports pgtable tests for semantics compliance
+#
+---
+| arch |status|
+---
+|   alpha: | TODO |
+| arc: | TODO |
+| arm: | TODO |
+|   arm64: |  ok  |
+| c6x: | TODO |
+|csky: | TODO |
+|   h8300: | TODO |
+| hexagon: | TODO |
+|ia64: | TODO |
+|m68k: | TODO |
+|  microblaze: | TODO |
+|mips: | TODO |
+|   nds32: | TODO |
+|   nios2: | TODO |
+|openrisc: | TODO |
+|  parisc: | TODO |
+| powerpc: | TODO |


Say ok on ppc32


+|   riscv: | TODO |
+|s390: | TODO |
+|  sh: | TODO |
+|  

Re: [PATCH] mm/pgtable/debug: Fix test validating architecture page table helpers

[Christophe Leroy]

Le 18/09/2019 à 09:32, Anshuman Khandual a écrit :



On 09/13/2019 11:53 AM, Christophe Leroy wrote:

Fix build failure on powerpc.

Fix preemption imbalance.

Signed-off-by: Christophe Leroy 
---
  mm/arch_pgtable_test.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
index 8b4a92756ad8..f2b3c9ec35fa 100644
--- a/mm/arch_pgtable_test.c
+++ b/mm/arch_pgtable_test.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
@@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)

p4d_clear_tests(p4dp);
pgd_clear_tests(mm, pgdp);
  
+	pte_unmap(ptep);

+
pmd_populate_tests(mm, pmdp, saved_ptep);
pud_populate_tests(mm, pudp, saved_pmdp);
p4d_populate_tests(mm, p4dp, saved_pudp);



Hello Christophe,

I am planning to fold this fix into the current patch and retain your
Signed-off-by. Are you okay with it ?



No problem, do whatever is convenient for you. You can keep the 
signed-off-by, or use tested-by: as I tested it on PPC32.


Christophe

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

Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers

[Christophe Leroy]

Le 19/09/2019 à 06:56, Anshuman Khandual a écrit :



On 09/18/2019 09:56 PM, Christophe Leroy wrote:



Le 18/09/2019 à 07:04, Anshuman Khandual a écrit :



On 09/13/2019 03:31 PM, Christophe Leroy wrote:



Le 13/09/2019 à 11:02, Anshuman Khandual a écrit :



+#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)


#ifdefs have to be avoided as much as possible, see below


Yeah but it has been bit difficult to avoid all these $ifdef because of the
availability (or lack of it) for all these pgtable helpers in various config
combinations on all platforms.


As far as I can see these pgtable helpers should exist everywhere at least via 
asm-generic/ files.


But they might not actually do the right thing.



Can you spot a particular config which fails ?


Lets consider the following example (after removing the $ifdefs around it)
which though builds successfully but fails to pass the intended test. This
is with arm64 config 4K pages sizes with 39 bits VA space which ends up
with a 3 level page table arrangement.

static void __init p4d_clear_tests(p4d_t *p4dp)
{
  p4d_t p4d = READ_ONCE(*p4dp);


My suggestion was not to completely drop the #ifdef but to do like you did in 
pgd_clear_tests() for instance, ie to add the following test on top of the 
function:

 if (mm_pud_folded(mm) || is_defined(__ARCH_HAS_5LEVEL_HACK))
     return;



Sometimes this does not really work. On some platforms, combination of
__PAGETABLE_PUD_FOLDED and __ARCH_HAS_5LEVEL_HACK decide whether the
helpers such as __pud() or __pgd() is even available for that platform.
Ideally it should have been through generic falls backs in include/*/
but I guess there might be bugs on the platform or it has not been
changed to adopt 5 level page table framework with required folding
macros etc.


Yes. As I suggested below, most likely that's better to retain the 
#ifdef __ARCH_HAS_5LEVEL_HACK but change the #ifdef 
__PAGETABLE_PUD_FOLDED by a runtime test of mm_pud_folded(mm)


As pointed by Gerald, some arches don't have __PAGETABLE_PUD_FOLDED 
because they are deciding dynamically if they fold the level on not, but 
have mm_pud_folded(mm)






  p4d = __p4d(p4d_val(p4d) | RANDOM_ORVALUE);
  WRITE_ONCE(*p4dp, p4d);
  p4d_clear(p4dp);
  p4d = READ_ONCE(*p4dp);
  WARN_ON(!p4d_none(p4d));
}

The following test hits an error at WARN_ON(!p4d_none(p4d))

[   16.757333] [ cut here ]
[   16.758019] WARNING: CPU: 11 PID: 1 at mm/arch_pgtable_test.c:187 
arch_pgtable_tests_init+0x24c/0x474


[...]


[   16.781282] ---[ end trace 042e6c40c0a3b038 ]---

On arm64 (4K page size|39 bits VA|3 level page table)

#elif CONFIG_PGTABLE_LEVELS == 3    /* Applicable here */
#define __ARCH_USE_5LEVEL_HACK
#include 

Which pulls in

#include 

which pulls in

#include 

which defines

static inline int p4d_none(p4d_t p4d)
{
  return 0;
}

which will invariably trigger WARN_ON(!p4d_none(p4d)).

Similarly for next test p4d_populate_tests() which will always be
successful because p4d_bad() invariably returns negative.

static inline int p4d_bad(p4d_t p4d)
{
  return 0;
}

static void __init p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp,
    pud_t *pudp)
{
  p4d_t p4d;

  /*
   * This entry points to next level page table page.
   * Hence this must not qualify as p4d_bad().
   */
  pud_clear(pudp);
  p4d_clear(p4dp);
  p4d_populate(mm, p4dp, pudp);
  p4d = READ_ONCE(*p4dp);
  WARN_ON(p4d_bad(p4d));
}

We should not run these tests for the above config because they are
not applicable and will invariably produce same result.



[...]



So it shouldn't be an issue. Maybe if a couple of arches miss them, the best 
would be to fix the arches, since that's the purpose of your testsuite isn't it 
?


The run time failures as explained previously is because of the folding which
needs to be protected as they are not even applicable. The compile time
failures are because pxx_populate() signatures are platform specific depending
on how many page table levels they really support.



So IIUC, the compiletime problem is around __ARCH_HAS_5LEVEL_HACK. For all #if 
!defined(__PAGETABLE_PXX_FOLDED), something equivalent to the following should 
make the trick.

 if (mm_pxx_folded())
     return;


For the __ARCH_HAS_5LEVEL_HACK stuff, I think we should be able to regroup all 
impacted functions inside a single #ifdef __ARCH_HAS_5LEVEL_HACK


I was wondering if it will be better to

1) Minimize all #ifdefs in the code which might fail on some platforms
2) Restrict proposed test module to platforms where it builds and runs
3) Enable other platforms afterwards after fixing their build problems or other 
requirements


I understand that __ARCH_HAS_5LEVEL_HACK is an HACK as its name 
suggests, so you can't expect all platforms to go for

Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers

[Christophe Leroy]

Le 18/09/2019 à 07:04, Anshuman Khandual a écrit :



On 09/13/2019 03:31 PM, Christophe Leroy wrote:



Le 13/09/2019 à 11:02, Anshuman Khandual a écrit :



+#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)


#ifdefs have to be avoided as much as possible, see below


Yeah but it has been bit difficult to avoid all these $ifdef because of the
availability (or lack of it) for all these pgtable helpers in various config
combinations on all platforms.


As far as I can see these pgtable helpers should exist everywhere at least via 
asm-generic/ files.


But they might not actually do the right thing.



Can you spot a particular config which fails ?


Lets consider the following example (after removing the $ifdefs around it)
which though builds successfully but fails to pass the intended test. This
is with arm64 config 4K pages sizes with 39 bits VA space which ends up
with a 3 level page table arrangement.

static void __init p4d_clear_tests(p4d_t *p4dp)
{
 p4d_t p4d = READ_ONCE(*p4dp);


My suggestion was not to completely drop the #ifdef but to do like you 
did in pgd_clear_tests() for instance, ie to add the following test on 
top of the function:


if (mm_pud_folded(mm) || is_defined(__ARCH_HAS_5LEVEL_HACK))
return;



 p4d = __p4d(p4d_val(p4d) | RANDOM_ORVALUE);
 WRITE_ONCE(*p4dp, p4d);
 p4d_clear(p4dp);
 p4d = READ_ONCE(*p4dp);
 WARN_ON(!p4d_none(p4d));
}

The following test hits an error at WARN_ON(!p4d_none(p4d))

[   16.757333] [ cut here ]
[   16.758019] WARNING: CPU: 11 PID: 1 at mm/arch_pgtable_test.c:187 
arch_pgtable_tests_init+0x24c/0x474
[   16.759455] Modules linked in:
[   16.759952] CPU: 11 PID: 1 Comm: swapper/0 Not tainted 
5.3.0-next-20190916-5-g61c218153bb8-dirty #222
[   16.761449] Hardware name: linux,dummy-virt (DT)
[   16.762185] pstate: 0045 (nzcv daif +PAN -UAO)
[   16.762964] pc : arch_pgtable_tests_init+0x24c/0x474
[   16.763750] lr : arch_pgtable_tests_init+0x174/0x474
[   16.764534] sp : ffc011d7bd50
[   16.765065] x29: ffc011d7bd50 x28: 1756bac0
[   16.765908] x27: ff85ddaf3000 x26: 02e8
[   16.766767] x25: ffc0111ce000 x24: ff85ddaf32e8
[   16.767606] x23: ff85ddaef278 x22: 0045cc844000
[   16.768445] x21: 00065daef003 x20: 1754
[   16.769283] x19: ff85ddb6 x18: 0014
[   16.770122] x17: 980426bb x16: 698594c6
[   16.770976] x15: 66e25a88 x14: 
[   16.771813] x13: 1754 x12: 000a
[   16.772651] x11: ff85fcfd0a40 x10: 0001
[   16.773488] x9 : 0008 x8 : ffc01143ab26
[   16.774336] x7 :  x6 : 
[   16.775180] x5 :  x4 : 
[   16.776018] x3 : 1756bbe8 x2 : 00065daeb003
[   16.776856] x1 : 0065daeb x0 : f000
[   16.777693] Call trace:
[   16.778092]  arch_pgtable_tests_init+0x24c/0x474
[   16.778843]  do_one_initcall+0x74/0x1b0
[   16.779458]  kernel_init_freeable+0x1cc/0x290
[   16.780151]  kernel_init+0x10/0x100
[   16.780710]  ret_from_fork+0x10/0x18
[   16.781282] ---[ end trace 042e6c40c0a3b038 ]---

On arm64 (4K page size|39 bits VA|3 level page table)

#elif CONFIG_PGTABLE_LEVELS == 3/* Applicable here */
#define __ARCH_USE_5LEVEL_HACK
#include 

Which pulls in

#include 

which pulls in

#include 

which defines

static inline int p4d_none(p4d_t p4d)
{
 return 0;
}

which will invariably trigger WARN_ON(!p4d_none(p4d)).

Similarly for next test p4d_populate_tests() which will always be
successful because p4d_bad() invariably returns negative.

static inline int p4d_bad(p4d_t p4d)
{
 return 0;
}

static void __init p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp,
   pud_t *pudp)
{
 p4d_t p4d;

 /*
  * This entry points to next level page table page.
  * Hence this must not qualify as p4d_bad().
  */
 pud_clear(pudp);
 p4d_clear(p4dp);
 p4d_populate(mm, p4dp, pudp);
 p4d = READ_ONCE(*p4dp);
 WARN_ON(p4d_bad(p4d));
}

We should not run these tests for the above config because they are
not applicable and will invariably produce same result.









[...]


+#if !defined(__PAGETABLE_PUD_FOLDED) && !defined(__ARCH_HAS_5LEVEL_HACK)


The same can be done here.


IIRC not only the page table helpers but there are data types (pxx_t) which
were not present on various configs and these wrappers help prevent build
failures. Any ways will try and see if this can be improved further. But
meanwhile if you have some suggestions, please do let me know.


pgt_t and pmd_t are everywhere I guess.
then pud_t and p4d_t have fallbacks in asm-generic files.


Lets take another example where it fails to compile. On arm64 with 16K
page siz

Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers

[Christophe Leroy]

Le 13/09/2019 à 11:02, Anshuman Khandual a écrit :



+#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)


#ifdefs have to be avoided as much as possible, see below


Yeah but it has been bit difficult to avoid all these $ifdef because of the
availability (or lack of it) for all these pgtable helpers in various config
combinations on all platforms.


As far as I can see these pgtable helpers should exist everywhere at 
least via asm-generic/ files.


Can you spot a particular config which fails ?







[...]


+#if !defined(__PAGETABLE_PUD_FOLDED) && !defined(__ARCH_HAS_5LEVEL_HACK)


The same can be done here.


IIRC not only the page table helpers but there are data types (pxx_t) which
were not present on various configs and these wrappers help prevent build
failures. Any ways will try and see if this can be improved further. But
meanwhile if you have some suggestions, please do let me know.


pgt_t and pmd_t are everywhere I guess.
then pud_t and p4d_t have fallbacks in asm-generic files.

So it shouldn't be an issue. Maybe if a couple of arches miss them, the 
best would be to fix the arches, since that's the purpose of your 
testsuite isn't it ?



Christophe

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

Re: [PATCH] mm/pgtable/debug: Fix test validating architecture page table helpers

[Christophe Leroy]

Le 13/09/2019 à 09:03, Christophe Leroy a écrit :



Le 13/09/2019 à 08:58, Anshuman Khandual a écrit :

On 09/13/2019 11:53 AM, Christophe Leroy wrote:

Fix build failure on powerpc.

Fix preemption imbalance.

Signed-off-by: Christophe Leroy 
---
  mm/arch_pgtable_test.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
index 8b4a92756ad8..f2b3c9ec35fa 100644
--- a/mm/arch_pgtable_test.c
+++ b/mm/arch_pgtable_test.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 


This is okay.


  #include 
  #include 
@@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)
  p4d_clear_tests(p4dp);
  pgd_clear_tests(mm, pgdp);
+    pte_unmap(ptep);
+


Now the preemption imbalance via pte_alloc_map() path i.e

pte_alloc_map() -> pte_offset_map() -> kmap_atomic()

Is not this very much powerpc 32 specific or this will be applicable
for all platform which uses kmap_XXX() to map high memory ?



See 
https://elixir.bootlin.com/linux/v5.3-rc8/source/include/linux/highmem.h#L91 



I think it applies at least to all arches using the generic implementation.

Applies also to arm:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/mm/highmem.c#L52

Applies also to mips:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/mips/mm/highmem.c#L47

Same on sparc:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/sparc/mm/highmem.c#L52 



Same on x86:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/mm/highmem_32.c#L34 



I have not checked others, but I guess it is like that for all.




Seems like I answered too quickly. All kmap_atomic() do 
preempt_disable(), but not all pte_alloc_map() call kmap_atomic().


However, for instance ARM does:

https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/include/asm/pgtable.h#L200

And X86 as well:

https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/include/asm/pgtable_32.h#L51

Microblaze also:

https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/microblaze/include/asm/pgtable.h#L495

Christophe

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

Re: [PATCH] mm/pgtable/debug: Fix test validating architecture page table helpers

[Christophe Leroy]

Le 13/09/2019 à 08:58, Anshuman Khandual a écrit :

On 09/13/2019 11:53 AM, Christophe Leroy wrote:

Fix build failure on powerpc.

Fix preemption imbalance.

Signed-off-by: Christophe Leroy 
---
  mm/arch_pgtable_test.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
index 8b4a92756ad8..f2b3c9ec35fa 100644
--- a/mm/arch_pgtable_test.c
+++ b/mm/arch_pgtable_test.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 


This is okay.


  #include 
  #include 
  
@@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)

p4d_clear_tests(p4dp);
pgd_clear_tests(mm, pgdp);
  
+	pte_unmap(ptep);

+


Now the preemption imbalance via pte_alloc_map() path i.e

pte_alloc_map() -> pte_offset_map() -> kmap_atomic()

Is not this very much powerpc 32 specific or this will be applicable
for all platform which uses kmap_XXX() to map high memory ?



See 
https://elixir.bootlin.com/linux/v5.3-rc8/source/include/linux/highmem.h#L91


I think it applies at least to all arches using the generic implementation.

Applies also to arm:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/mm/highmem.c#L52

Applies also to mips:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/mips/mm/highmem.c#L47

Same on sparc:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/sparc/mm/highmem.c#L52

Same on x86:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/mm/highmem_32.c#L34

I have not checked others, but I guess it is like that for all.

Christophe

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

Re: [PATCH V2 0/2] mm/debug: Add tests for architecture exported page table helpers

[Christophe Leroy]

Le 13/09/2019 à 08:24, Anshuman Khandual a écrit :



On 09/12/2019 08:12 PM, Christophe Leroy wrote:

Hi,

I didn't get patch 1 of this series, and it is not on linuxppc-dev patchwork 
either. Can you resend ?


Its there on linux-mm patchwork and copied on linux-ker...@vger.kernel.org
as well. The CC list for the first patch was different than the second one.

https://patchwork.kernel.org/patch/11142317/

Let me know if you can not find it either on MM or LKML list.



I finaly found it on linux-mm archive, thanks. See my other mails and my 
fixing patch.


Christophe

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

Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers

[Christophe Leroy]

Le 12/09/2019 à 17:52, Christophe Leroy a écrit :



Le 12/09/2019 à 17:36, Christophe Leroy a écrit :



Le 12/09/2019 à 17:00, Christophe Leroy a écrit :



On 09/12/2019 06:02 AM, Anshuman Khandual wrote:
This adds a test module which will validate architecture page table 
helpers
and accessors regarding compliance with generic MM semantics 
expectations.
This will help various architectures in validating changes to the 
existing

page table helpers or addition of new ones.

Test page table and memory pages creating it's entries at various 
level are
all allocated from system memory with required alignments. If memory 
pages
with required size and alignment could not be allocated, then all 
depending

individual tests are skipped.


Build failure on powerpc book3s/32. This is because asm/highmem.h is 
missing. It can't be included from asm/book3s/32/pgtable.h because it 
creates circular dependency. So it has to be included from 
mm/arch_pgtable_test.c


In fact it is  that needs to be added, adding 
 directly provokes build failure at link time.




I get the following failure,

[    0.704685] [ cut here ]
[    0.709239] initcall arch_pgtable_tests_init+0x0/0x228 returned with 
preemption imbalance


preempt_disable() is called from kmap_atomic() which is called from 
pte_alloc_map() via pte_offset_map().


pte_unmap() has to be called to release the mapped pte and re-enable 
preemtion.


Christophe


[    0.717539] WARNING: CPU: 0 PID: 1 at init/main.c:952 
do_one_initcall+0x18c/0x1d4
[    0.724922] CPU: 0 PID: 1 Comm: swapper Not tainted 
5.3.0-rc7-s3k-dev-00880-g28fd02a838e5-dirty #2307

[    0.734070] NIP:  c070e674 LR: c070e674 CTR: c001292c
[    0.739084] REGS: df4a5dd0 TRAP: 0700   Not tainted 
(5.3.0-rc7-s3k-dev-00880-g28fd02a838e5-dirty)

[    0.747975] MSR:  00029032   CR: 28000222  XER: 
[    0.754628]
[    0.754628] GPR00: c070e674 df4a5e88 df4a 004e 000a 
 00ca 38207265
[    0.754628] GPR08: 1032 0800   22000422 
 c0004a7c 
[    0.754628] GPR16:      
c081 c080 c0816f30
[    0.754628] GPR24: c070dc20 c074702c 0006 009c  
c0724494 c074e140 

[    0.789339] NIP [c070e674] do_one_initcall+0x18c/0x1d4
[    0.794435] LR [c070e674] do_one_initcall+0x18c/0x1d4
[    0.799437] Call Trace:
[    0.801867] [df4a5e88] [c070e674] do_one_initcall+0x18c/0x1d4 
(unreliable)

[    0.808694] [df4a5ee8] [c070e8c0] kernel_init_freeable+0x204/0x2dc
[    0.814830] [df4a5f28] [c0004a94] kernel_init+0x18/0x110
[    0.820107] [df4a5f38] [c00122ac] ret_from_kernel_thread+0x14/0x1c
[    0.826220] Instruction dump:
[    0.829161] 4beb1069 7d2000a6 61298000 7d200124 89210008 2f89 
41be0048 3c60c06a
[    0.836849] 38a10008 7fa4eb78 3863cacc 4b915115 <0fe0> 482c 
81220070 712a0004

[    0.844723] ---[ end trace 969d686308d40b33 ]---

Then starting init fails:

[    3.894074] Run /init as init process
[    3.898403] Failed to execute /init (error -14)
[    3.903009] Run /sbin/init as init process
[    3.907172] Run /etc/init as init process
[    3.911251] Run /bin/init as init process
[    3.915513] Run /bin/sh as init process
[    3.919471] Starting init: /bin/sh exists but couldn't execute it 
(error -14)
[    3.926732] Kernel panic - not syncing: No working init found.  Try 
passing init= option to kernel. See Linux 
Documentation/admin-guide/init.rst for guidance.
[    3.940864] CPU: 0 PID: 1 Comm: init Tainted: G    W 
5.3.0-rc7-s3k-dev-00880-g28fd02a838e5-dirty #2307

[    3.951165] Call Trace:
[    3.953617] [df4a5ec8] [c002392c] panic+0x12c/0x320 (unreliable)
[    3.959621] [df4a5f28] [c0004b8c] rootfs_mount+0x0/0x2c
[    3.964849] [df4a5f38] [c00122ac] ret_from_kernel_thread+0x14/0x1c


Christophe


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

[PATCH] mm/pgtable/debug: Fix test validating architecture page table helpers

[Christophe Leroy]

Fix build failure on powerpc.

Fix preemption imbalance.

Signed-off-by: Christophe Leroy 
---
 mm/arch_pgtable_test.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
index 8b4a92756ad8..f2b3c9ec35fa 100644
--- a/mm/arch_pgtable_test.c
+++ b/mm/arch_pgtable_test.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)
p4d_clear_tests(p4dp);
pgd_clear_tests(mm, pgdp);
 
+   pte_unmap(ptep);
+
pmd_populate_tests(mm, pmdp, saved_ptep);
pud_populate_tests(mm, pudp, saved_pmdp);
p4d_populate_tests(mm, p4dp, saved_pudp);
-- 
2.13.3


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

Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers

[Christophe Leroy]

Le 12/09/2019 à 08:02, Anshuman Khandual a écrit :

This adds a test module which will validate architecture page table helpers
and accessors regarding compliance with generic MM semantics expectations.
This will help various architectures in validating changes to the existing
page table helpers or addition of new ones.

Test page table and memory pages creating it's entries at various level are
all allocated from system memory with required alignments. If memory pages
with required size and alignment could not be allocated, then all depending
individual tests are skipped.



[...]



Suggested-by: Catalin Marinas 
Signed-off-by: Anshuman Khandual 
---
  arch/x86/include/asm/pgtable_64_types.h |   2 +
  mm/Kconfig.debug|  14 +
  mm/Makefile |   1 +
  mm/arch_pgtable_test.c  | 429 
  4 files changed, 446 insertions(+)
  create mode 100644 mm/arch_pgtable_test.c

diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 52e5f5f2240d..b882792a3999 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -40,6 +40,8 @@ static inline bool pgtable_l5_enabled(void)
  #define pgtable_l5_enabled() 0
  #endif /* CONFIG_X86_5LEVEL */
  
+#define mm_p4d_folded(mm) (!pgtable_l5_enabled())

+


This is specific to x86, should go in a separate patch.


  extern unsigned int pgdir_shift;
  extern unsigned int ptrs_per_p4d;
  
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug

index 327b3ebf23bf..ce9c397f7b07 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -117,3 +117,17 @@ config DEBUG_RODATA_TEST
  depends on STRICT_KERNEL_RWX
  ---help---
This option enables a testcase for the setting rodata read-only.
+
+config DEBUG_ARCH_PGTABLE_TEST
+   bool "Test arch page table helpers for semantics compliance"
+   depends on MMU
+   depends on DEBUG_KERNEL
+   help
+ This options provides a kernel module which can be used to test
+ architecture page table helper functions on various platform in
+ verifying if they comply with expected generic MM semantics. This
+ will help architectures code in making sure that any changes or
+ new additions of these helpers will still conform to generic MM
+ expected semantics.
+
+ If unsure, say N.
diff --git a/mm/Makefile b/mm/Makefile
index d996846697ef..bb572c5aa8c5 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -86,6 +86,7 @@ obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o
  obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o
  obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o
  obj-$(CONFIG_DEBUG_RODATA_TEST) += rodata_test.o
+obj-$(CONFIG_DEBUG_ARCH_PGTABLE_TEST) += arch_pgtable_test.o
  obj-$(CONFIG_PAGE_OWNER) += page_owner.o
  obj-$(CONFIG_CLEANCACHE) += cleancache.o
  obj-$(CONFIG_MEMORY_ISOLATION) += page_isolation.o
diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
new file mode 100644
index ..8b4a92756ad8
--- /dev/null
+++ b/mm/arch_pgtable_test.c
@@ -0,0 +1,429 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * This kernel module validates architecture page table helpers &
+ * accessors and helps in verifying their continued compliance with
+ * generic MM semantics.
+ *
+ * Copyright (C) 2019 ARM Ltd.
+ *
+ * Author: Anshuman Khandual 
+ */
+#define pr_fmt(fmt) "arch_pgtable_test: %s " fmt, __func__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


Add  (see other mails, build failure on ppc book3s/32)


+#include 
+#include 
+
+/*
+ * Basic operations
+ *
+ * mkold(entry)= An old and not a young entry
+ * mkyoung(entry)  = A young and not an old entry
+ * mkdirty(entry)  = A dirty and not a clean entry
+ * mkclean(entry)  = A clean and not a dirty entry
+ * mkwrite(entry)  = A write and not a write protected entry
+ * wrprotect(entry)= A write protected and not a write entry
+ * pxx_bad(entry)  = A mapped and non-table entry
+ * pxx_same(entry1, entry2)= Both entries hold the exact same value
+ */
+#define VMFLAGS(VM_READ|VM_WRITE|VM_EXEC)
+
+/*
+ * On s390 platform, the lower 12 bits are used to identify given page table
+ * entry type and for other arch specific requirements. But these bits might
+ * affect the ability to clear entries with pxx_clear(). So while loading up
+ * the entries skip all lower 12 bits in order to accommodate s390 platform.
+ * It does not have affect any other platform.
+ */
+#define RANDOM_ORVALUE (0xf000UL)
+#define RANDOM_NZVALUE (0xff)
+
+static bool pud_aligned;
+static bool pmd_aligned;
+
+static void pte_basic_tests(struct page *page, pgprot_t prot)
+{
+   pte_t pte = mk_pte(page, prot);
+
+   WARN_ON(!pte_same(pte, 

Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers

[Christophe Leroy]

Le 12/09/2019 à 17:36, Christophe Leroy a écrit :



Le 12/09/2019 à 17:00, Christophe Leroy a écrit :



On 09/12/2019 06:02 AM, Anshuman Khandual wrote:
This adds a test module which will validate architecture page table 
helpers
and accessors regarding compliance with generic MM semantics 
expectations.
This will help various architectures in validating changes to the 
existing

page table helpers or addition of new ones.

Test page table and memory pages creating it's entries at various 
level are
all allocated from system memory with required alignments. If memory 
pages
with required size and alignment could not be allocated, then all 
depending

individual tests are skipped.


Build failure on powerpc book3s/32. This is because asm/highmem.h is 
missing. It can't be included from asm/book3s/32/pgtable.h because it 
creates circular dependency. So it has to be included from 
mm/arch_pgtable_test.c


In fact it is  that needs to be added, adding 
 directly provokes build failure at link time.




I get the following failure,

[0.704685] [ cut here ]
[0.709239] initcall arch_pgtable_tests_init+0x0/0x228 returned with 
preemption imbalance
[0.717539] WARNING: CPU: 0 PID: 1 at init/main.c:952 
do_one_initcall+0x18c/0x1d4
[0.724922] CPU: 0 PID: 1 Comm: swapper Not tainted 
5.3.0-rc7-s3k-dev-00880-g28fd02a838e5-dirty #2307

[0.734070] NIP:  c070e674 LR: c070e674 CTR: c001292c
[0.739084] REGS: df4a5dd0 TRAP: 0700   Not tainted 
(5.3.0-rc7-s3k-dev-00880-g28fd02a838e5-dirty)

[0.747975] MSR:  00029032   CR: 28000222  XER: 
[0.754628]
[0.754628] GPR00: c070e674 df4a5e88 df4a 004e 000a 
 00ca 38207265
[0.754628] GPR08: 1032 0800   22000422 
 c0004a7c 
[0.754628] GPR16:      
c081 c080 c0816f30
[0.754628] GPR24: c070dc20 c074702c 0006 009c  
c0724494 c074e140 

[0.789339] NIP [c070e674] do_one_initcall+0x18c/0x1d4
[0.794435] LR [c070e674] do_one_initcall+0x18c/0x1d4
[0.799437] Call Trace:
[0.801867] [df4a5e88] [c070e674] do_one_initcall+0x18c/0x1d4 
(unreliable)

[0.808694] [df4a5ee8] [c070e8c0] kernel_init_freeable+0x204/0x2dc
[0.814830] [df4a5f28] [c0004a94] kernel_init+0x18/0x110
[0.820107] [df4a5f38] [c00122ac] ret_from_kernel_thread+0x14/0x1c
[0.826220] Instruction dump:
[0.829161] 4beb1069 7d2000a6 61298000 7d200124 89210008 2f89 
41be0048 3c60c06a
[0.836849] 38a10008 7fa4eb78 3863cacc 4b915115 <0fe0> 482c 
81220070 712a0004

[0.844723] ---[ end trace 969d686308d40b33 ]---

Then starting init fails:

[3.894074] Run /init as init process
[3.898403] Failed to execute /init (error -14)
[3.903009] Run /sbin/init as init process
[3.907172] Run /etc/init as init process
[3.911251] Run /bin/init as init process
[3.915513] Run /bin/sh as init process
[3.919471] Starting init: /bin/sh exists but couldn't execute it 
(error -14)
[3.926732] Kernel panic - not syncing: No working init found.  Try 
passing init= option to kernel. See Linux 
Documentation/admin-guide/init.rst for guidance.
[3.940864] CPU: 0 PID: 1 Comm: init Tainted: GW 
5.3.0-rc7-s3k-dev-00880-g28fd02a838e5-dirty #2307

[3.951165] Call Trace:
[3.953617] [df4a5ec8] [c002392c] panic+0x12c/0x320 (unreliable)
[3.959621] [df4a5f28] [c0004b8c] rootfs_mount+0x0/0x2c
[3.964849] [df4a5f38] [c00122ac] ret_from_kernel_thread+0x14/0x1c


Christophe

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

Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers

[Christophe Leroy]

Le 12/09/2019 à 17:00, Christophe Leroy a écrit :



On 09/12/2019 06:02 AM, Anshuman Khandual wrote:
This adds a test module which will validate architecture page table 
helpers
and accessors regarding compliance with generic MM semantics 
expectations.
This will help various architectures in validating changes to the 
existing

page table helpers or addition of new ones.

Test page table and memory pages creating it's entries at various 
level are
all allocated from system memory with required alignments. If memory 
pages
with required size and alignment could not be allocated, then all 
depending

individual tests are skipped.


Build failure on powerpc book3s/32. This is because asm/highmem.h is 
missing. It can't be included from asm/book3s/32/pgtable.h because it 
creates circular dependency. So it has to be included from 
mm/arch_pgtable_test.c


In fact it is  that needs to be added, adding 
 directly provokes build failure at link time.


Christophe





   CC  mm/arch_pgtable_test.o
In file included from ./arch/powerpc/include/asm/book3s/pgtable.h:8:0,
  from ./arch/powerpc/include/asm/pgtable.h:18,
  from ./include/linux/mm.h:99,
  from ./arch/powerpc/include/asm/io.h:29,
  from ./include/linux/io.h:13,
  from ./include/linux/irq.h:20,
  from ./arch/powerpc/include/asm/hardirq.h:6,
  from ./include/linux/hardirq.h:9,
  from ./include/linux/interrupt.h:11,
  from ./include/linux/kernel_stat.h:9,
  from ./include/linux/cgroup.h:26,
  from ./include/linux/hugetlb.h:9,
  from mm/arch_pgtable_test.c:14:
mm/arch_pgtable_test.c: In function 'arch_pgtable_tests_init':
./arch/powerpc/include/asm/book3s/32/pgtable.h:365:13: error: implicit 
declaration of function 'kmap_atomic' 
[-Werror=implicit-function-declaration]

   ((pte_t *)(kmap_atomic(pmd_page(*(dir))) + \
  ^
./include/linux/mm.h:2008:31: note: in expansion of macro 'pte_offset_map'
   (pte_alloc(mm, pmd) ? NULL : pte_offset_map(pmd, address))
    ^
mm/arch_pgtable_test.c:377:9: note: in expansion of macro 'pte_alloc_map'
   ptep = pte_alloc_map(mm, pmdp, vaddr);
  ^
cc1: some warnings being treated as errors
make[2]: *** [mm/arch_pgtable_test.o] Error 1


Christophe




Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Greg Kroah-Hartman 
Cc: Thomas Gleixner 
Cc: Mike Rapoport 
Cc: Jason Gunthorpe 
Cc: Dan Williams 
Cc: Peter Zijlstra 
Cc: Michal Hocko 
Cc: Mark Rutland 
Cc: Mark Brown 
Cc: Steven Price 
Cc: Ard Biesheuvel 
Cc: Masahiro Yamada 
Cc: Kees Cook 
Cc: Tetsuo Handa 
Cc: Matthew Wilcox 
Cc: Sri Krishna chowdary 
Cc: Dave Hansen 
Cc: Russell King - ARM Linux 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: "David S. Miller" 
Cc: Vineet Gupta 
Cc: James Hogan 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Kirill A. Shutemov 
Cc: Gerald Schaefer 
Cc: Christophe Leroy 
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-ker...@vger.kernel.org

Suggested-by: Catalin Marinas 
Signed-off-by: Anshuman Khandual 
---
  arch/x86/include/asm/pgtable_64_types.h |   2 +
  mm/Kconfig.debug    |  14 +
  mm/Makefile |   1 +
  mm/arch_pgtable_test.c  | 429 
  4 files changed, 446 insertions(+)
  create mode 100644 mm/arch_pgtable_test.c

diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h

index 52e5f5f2240d..b882792a3999 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -40,6 +40,8 @@ static inline bool pgtable_l5_enabled(void)
  #define pgtable_l5_enabled() 0
  #endif /* CONFIG_X86_5LEVEL */
+#define mm_p4d_folded(mm) (!pgtable_l5_enabled())
+
  extern unsigned int pgdir_shift;
  extern unsigned int ptrs_per_p4d;
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 327b3ebf23bf..ce9c397f7b07 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -117,3 +117,17 @@ config DEBUG_RODATA_TEST
  depends on STRICT_KERNEL_RWX
  ---help---
    This option enables a testcase for the setting rodata read-only.
+
+config DEBUG_ARCH_PGTABLE_TEST
+    bool "Test arch page table helpers for semantics compliance"
+    depends on MMU
+    depends on DEBUG_KERNEL
+    help
+  This options provides a kernel module which can be used to test
+  architecture page table helper functions on various platform in
+  verifying if they comply with expected generic MM semantics. This
+  will help architectures code in making s

Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers

[Christophe Leroy]

On 09/12/2019 06:02 AM, Anshuman Khandual wrote:

This adds a test module which will validate architecture page table helpers
and accessors regarding compliance with generic MM semantics expectations.
This will help various architectures in validating changes to the existing
page table helpers or addition of new ones.

Test page table and memory pages creating it's entries at various level are
all allocated from system memory with required alignments. If memory pages
with required size and alignment could not be allocated, then all depending
individual tests are skipped.


Build failure on powerpc book3s/32. This is because asm/highmem.h is 
missing. It can't be included from asm/book3s/32/pgtable.h because it 
creates circular dependency. So it has to be included from 
mm/arch_pgtable_test.c




  CC  mm/arch_pgtable_test.o
In file included from ./arch/powerpc/include/asm/book3s/pgtable.h:8:0,
 from ./arch/powerpc/include/asm/pgtable.h:18,
 from ./include/linux/mm.h:99,
 from ./arch/powerpc/include/asm/io.h:29,
 from ./include/linux/io.h:13,
 from ./include/linux/irq.h:20,
 from ./arch/powerpc/include/asm/hardirq.h:6,
 from ./include/linux/hardirq.h:9,
 from ./include/linux/interrupt.h:11,
 from ./include/linux/kernel_stat.h:9,
 from ./include/linux/cgroup.h:26,
 from ./include/linux/hugetlb.h:9,
 from mm/arch_pgtable_test.c:14:
mm/arch_pgtable_test.c: In function 'arch_pgtable_tests_init':
./arch/powerpc/include/asm/book3s/32/pgtable.h:365:13: error: implicit 
declaration of function 'kmap_atomic' 
[-Werror=implicit-function-declaration]

  ((pte_t *)(kmap_atomic(pmd_page(*(dir))) + \
 ^
./include/linux/mm.h:2008:31: note: in expansion of macro 'pte_offset_map'
  (pte_alloc(mm, pmd) ? NULL : pte_offset_map(pmd, address))
   ^
mm/arch_pgtable_test.c:377:9: note: in expansion of macro 'pte_alloc_map'
  ptep = pte_alloc_map(mm, pmdp, vaddr);
 ^
cc1: some warnings being treated as errors
make[2]: *** [mm/arch_pgtable_test.o] Error 1


Christophe




Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Greg Kroah-Hartman 
Cc: Thomas Gleixner 
Cc: Mike Rapoport 
Cc: Jason Gunthorpe 
Cc: Dan Williams 
Cc: Peter Zijlstra 
Cc: Michal Hocko 
Cc: Mark Rutland 
Cc: Mark Brown 
Cc: Steven Price 
Cc: Ard Biesheuvel 
Cc: Masahiro Yamada 
Cc: Kees Cook 
Cc: Tetsuo Handa 
Cc: Matthew Wilcox 
Cc: Sri Krishna chowdary 
Cc: Dave Hansen 
Cc: Russell King - ARM Linux 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: "David S. Miller" 
Cc: Vineet Gupta 
Cc: James Hogan 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Kirill A. Shutemov 
Cc: Gerald Schaefer 
Cc: Christophe Leroy 
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-ker...@vger.kernel.org

Suggested-by: Catalin Marinas 
Signed-off-by: Anshuman Khandual 
---
  arch/x86/include/asm/pgtable_64_types.h |   2 +
  mm/Kconfig.debug|  14 +
  mm/Makefile |   1 +
  mm/arch_pgtable_test.c  | 429 
  4 files changed, 446 insertions(+)
  create mode 100644 mm/arch_pgtable_test.c

diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 52e5f5f2240d..b882792a3999 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -40,6 +40,8 @@ static inline bool pgtable_l5_enabled(void)
  #define pgtable_l5_enabled() 0
  #endif /* CONFIG_X86_5LEVEL */
  
+#define mm_p4d_folded(mm) (!pgtable_l5_enabled())

+
  extern unsigned int pgdir_shift;
  extern unsigned int ptrs_per_p4d;
  
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug

index 327b3ebf23bf..ce9c397f7b07 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -117,3 +117,17 @@ config DEBUG_RODATA_TEST
  depends on STRICT_KERNEL_RWX
  ---help---
This option enables a testcase for the setting rodata read-only.
+
+config DEBUG_ARCH_PGTABLE_TEST
+   bool "Test arch page table helpers for semantics compliance"
+   depends on MMU
+   depends on DEBUG_KERNEL
+   help
+ This options provides a kernel module which can be used to test
+ architecture page table helper functions on various platform in
+ verifying if they comply with expected generic MM semantics. This
+ will help architectures code in making sure that any changes or
+ new additions of these helpers will still conform to generic MM
+ expected semantics.
+
+ If unsure, say N.
diff --gi

Re: [PATCH V2 0/2] mm/debug: Add tests for architecture exported page table helpers

[Christophe Leroy]

Hi,

I didn't get patch 1 of this series, and it is not on linuxppc-dev 
patchwork either. Can you resend ?


Thanks
Christophe

Le 12/09/2019 à 08:02, Anshuman Khandual a écrit :

This series adds a test validation for architecture exported page table
helpers. Patch in the series adds basic transformation tests at various
levels of the page table. Before that it exports gigantic page allocation
function from HugeTLB.

This test was originally suggested by Catalin during arm64 THP migration
RFC discussion earlier. Going forward it can include more specific tests
with respect to various generic MM functions like THP, HugeTLB etc and
platform specific tests.

https://lore.kernel.org/linux-mm/20190628102003.ga56...@arrakis.emea.arm.com/

Testing:

Successfully build and boot tested on both arm64 and x86 platforms without
any test failing. Only build tested on some other platforms.

But I would really appreciate if folks can help validate this test on other
platforms and report back problems. All suggestions, comments and inputs
welcome. Thank you.

Changes in V2:

- Fixed small typo error in MODULE_DESCRIPTION()
- Fixed m64k build problems for lvalue concerns in pmd_xxx_tests()
- Fixed dynamic page table level folding problems on x86 as per Kirril
- Fixed second pointers during pxx_populate_tests() per Kirill and Gerald
- Allocate and free pte table with pte_alloc_one/pte_free per Kirill
- Modified pxx_clear_tests() to accommodate s390 lower 12 bits situation
- Changed RANDOM_NZVALUE value from 0xbe to 0xff
- Changed allocation, usage, free sequence for saved_ptep
- Renamed VMA_FLAGS as VMFLAGS
- Implemented a new method for random vaddr generation
- Implemented some other cleanups
- Dropped extern reference to mm_alloc()
- Created and exported new alloc_gigantic_page_order()
- Dropped the custom allocator and used new alloc_gigantic_page_order()

Changes in V1:

https://lore.kernel.org/linux-mm/1567497706-8649-1-git-send-email-anshuman.khand...@arm.com/

- Added fallback mechanism for PMD aligned memory allocation failure

Changes in RFC V2:

https://lore.kernel.org/linux-mm/1565335998-22553-1-git-send-email-anshuman.khand...@arm.com/T/#u

- Moved test module and it's config from lib/ to mm/
- Renamed config TEST_ARCH_PGTABLE as DEBUG_ARCH_PGTABLE_TEST
- Renamed file from test_arch_pgtable.c to arch_pgtable_test.c
- Added relevant MODULE_DESCRIPTION() and MODULE_AUTHOR() details
- Dropped loadable module config option
- Basic tests now use memory blocks with required size and alignment
- PUD aligned memory block gets allocated with alloc_contig_range()
- If PUD aligned memory could not be allocated it falls back on PMD aligned
   memory block from page allocator and pud_* tests are skipped
- Clear and populate tests now operate on real in memory page table entries
- Dummy mm_struct gets allocated with mm_alloc()
- Dummy page table entries get allocated with [pud|pmd|pte]_alloc_[map]()
- Simplified [p4d|pgd]_basic_tests(), now has random values in the entries

Original RFC V1:

https://lore.kernel.org/linux-mm/1564037723-26676-1-git-send-email-anshuman.khand...@arm.com/

Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Greg Kroah-Hartman 
Cc: Thomas Gleixner 
Cc: Mike Rapoport 
Cc: Jason Gunthorpe 
Cc: Dan Williams 
Cc: Peter Zijlstra 
Cc: Michal Hocko 
Cc: Mark Rutland 
Cc: Mark Brown 
Cc: Steven Price 
Cc: Ard Biesheuvel 
Cc: Masahiro Yamada 
Cc: Kees Cook 
Cc: Tetsuo Handa 
Cc: Matthew Wilcox 
Cc: Sri Krishna chowdary 
Cc: Dave Hansen 
Cc: Russell King - ARM Linux 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: "David S. Miller" 
Cc: Vineet Gupta 
Cc: James Hogan 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Kirill A. Shutemov 
Cc: Gerald Schaefer 
Cc: Christophe Leroy 
Cc: Mike Kravetz 
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-ker...@vger.kernel.org

Anshuman Khandual (2):
   mm/hugetlb: Make alloc_gigantic_page() available for general use
   mm/pgtable/debug: Add test validating architecture page table helpers

  arch/x86/include/asm/pgtable_64_types.h |   2 +
  include/linux/hugetlb.h |   9 +
  mm/Kconfig.debug|  14 +
  mm/Makefile |   1 +
  mm/arch_pgtable_test.c  | 429 
  mm/hugetlb.c|  24 +-
  6 files changed, 477 insertions(+), 2 deletions(-)
  create mode 100644 mm/arch_pgtable_test.c



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

Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers

[Christophe Leroy]

On 09/10/2019 03:56 AM, Anshuman Khandual wrote:



On 09/09/2019 08:43 PM, Kirill A. Shutemov wrote:

On Mon, Sep 09, 2019 at 11:56:50AM +0530, Anshuman Khandual wrote:



On 09/07/2019 12:33 AM, Gerald Schaefer wrote:

On Fri, 6 Sep 2019 11:58:59 +0530
Anshuman Khandual  wrote:


On 09/05/2019 10:36 PM, Gerald Schaefer wrote:

On Thu, 5 Sep 2019 14:48:14 +0530
Anshuman Khandual  wrote:
   

[...]

+
+#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
+static void pud_clear_tests(pud_t *pudp)
+{
+   memset(pudp, RANDOM_NZVALUE, sizeof(pud_t));
+   pud_clear(pudp);
+   WARN_ON(!pud_none(READ_ONCE(*pudp)));
+}


For pgd/p4d/pud_clear(), we only clear if the page table level is present
and not folded. The memset() here overwrites the table type bits, so
pud_clear() will not clear anything on s390 and the pud_none() check will
fail.
Would it be possible to OR a (larger) random value into the table, so that
the lower 12 bits would be preserved?


So the suggestion is instead of doing memset() on entry with RANDOM_NZVALUE,
it should OR a large random value preserving lower 12 bits. Hmm, this should
still do the trick for other platforms, they just need non zero value. So on
s390, the lower 12 bits on the page table entry already has valid value while
entering this function which would make sure that pud_clear() really does
clear the entry ?


Yes, in theory the table entry on s390 would have the type set in the last
4 bits, so preserving those would be enough. If it does not conflict with
others, I would still suggest preserving all 12 bits since those would contain
arch-specific flags in general, just to be sure. For s390, the pte/pmd tests
would also work with the memset, but for consistency I think the same logic
should be used in all pxd_clear_tests.


Makes sense but..

There is a small challenge with this. Modifying individual bits on a given
page table entry from generic code like this test case is bit tricky. That
is because there are not enough helpers to create entries with an absolute
value. This would have been easier if all the platforms provided functions
like __pxx() which is not the case now. Otherwise something like this should
have worked.


pud_t pud = READ_ONCE(*pudp);
pud = __pud(pud_val(pud) | RANDOM_VALUE (keeping lower 12 bits 0))
WRITE_ONCE(*pudp, pud);

But __pud() will fail to build in many platforms.


Hmm, I simply used this on my system to make pud_clear_tests() work, not
sure if it works on all archs:

pud_val(*pudp) |= RANDOM_NZVALUE;


Which compiles on arm64 but then fails on x86 because of the way pmd_val()
has been defined there.


Use instead

*pudp = __pud(pud_val(*pudp) | RANDOM_NZVALUE);


Agreed.

As I had mentioned before this would have been really the cleanest approach.



It *should* be more portable.


Not really, because not all the platforms have __pxx() definitions right now.
Going with these will clearly cause build failures on affected platforms. Lets
examine __pud() for instance. It is defined only on these platforms.

arch/arm64/include/asm/pgtable-types.h: #define __pud(x) ((pud_t) { (x) 
} )
arch/mips/include/asm/pgtable-64.h: #define __pud(x) ((pud_t) { (x) 
})
arch/powerpc/include/asm/pgtable-be-types.h:#define __pud(x) ((pud_t) { 
cpu_to_be64(x) })
arch/powerpc/include/asm/pgtable-types.h:   #define __pud(x) ((pud_t) { (x) 
})
arch/s390/include/asm/page.h:   #define __pud(x) ((pud_t) { (x) 
} )
arch/sparc/include/asm/page_64.h:   #define __pud(x) ((pud_t) { (x) 
} )
arch/sparc/include/asm/page_64.h:   #define __pud(x) (x)
arch/x86/include/asm/pgtable.h: #define __pud(x) 
native_make_pud(x)


You missed:
arch/x86/include/asm/paravirt.h:static inline pud_t __pud(pudval_t val)
include/asm-generic/pgtable-nop4d-hack.h:#define __pud(x) 
   ((pud_t) { __pgd(x) })
include/asm-generic/pgtable-nopud.h:#define __pud(x) 
   ((pud_t) { __p4d(x) })




Similarly for __pmd()

arch/alpha/include/asm/page.h:  #define __pmd(x)  ((pmd_t) { 
(x) } )
arch/arm/include/asm/page-nommu.h:  #define __pmd(x)  (x)
arch/arm/include/asm/pgtable-2level-types.h:#define __pmd(x)  ((pmd_t) { 
(x) } )
arch/arm/include/asm/pgtable-2level-types.h:#define __pmd(x)  (x)
arch/arm/include/asm/pgtable-3level-types.h:#define __pmd(x)  ((pmd_t) { 
(x) } )
arch/arm/include/asm/pgtable-3level-types.h:#define __pmd(x)  (x)
arch/arm64/include/asm/pgtable-types.h: #define __pmd(x)  ((pmd_t) { 
(x) } )
arch/m68k/include/asm/page.h:   #define __pmd(x)  ((pmd_t) { { 
(x) }, })
arch/mips/include/asm/pgtable-64.h: #define __pmd(x)  ((pmd_t) { 
(x) } )
arch/nds32/include/asm/page.h:  #define __pmd(x)  (x)
arch/parisc/include/asm/page.h: #define __pmd(x)  ((pmd_t) { 
(x) } )
arch/parisc/include/asm/page.h: #define __pmd(x)  (x)

Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

[Christophe Leroy]

Le 31/01/2019 à 07:44, Christophe Leroy a écrit :



Le 31/01/2019 à 07:41, Mike Rapoport a écrit :

On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:



Le 21/01/2019 à 09:04, Mike Rapoport a écrit :

Add check for the return value of memblock_alloc*() functions and call
panic() in case of error.
The panic message repeats the one used by panicing memblock 
allocators with

adjustment of parameters to include only relevant ones.

The replacement was mostly automated with semantic patches like the one
below with manual massaging of format strings.

@@
expression ptr, size, align;
@@
ptr = memblock_alloc(size, align);
+ if (!ptr)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
size, align);

Signed-off-by: Mike Rapoport 
Reviewed-by: Guo Ren  # c-sky
Acked-by: Paul Burton  # MIPS
Acked-by: Heiko Carstens  # s390
Reviewed-by: Juergen Gross  # Xen
---


[...]


diff --git a/mm/sparse.c b/mm/sparse.c
index 7ea5dc6..ad94242 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c


[...]

@@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned 
long size, int nid)

  memblock_alloc_try_nid_raw(size, PAGE_SIZE,
  __pa(MAX_DMA_ADDRESS),
  MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+    if (!sparsemap_buf)
+    panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d 
from=%lx\n",

+  __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
+


memblock_alloc_try_nid_raw() does not panic (help explicitly says: 
Does not

zero allocated memory, does not panic if request cannot be satisfied.).


"Does not panic" does not mean it always succeeds.


I agree, but at least here you are changing the behaviour by making it 
panic explicitly. Are we sure there are not cases where the system could 
just continue functionning ? Maybe a WARN_ON() would be enough there ?


Looking more in details, it looks like everything is done to live with 
sparsemap_buf NULL, all functions using it check it so having it NULL 
shouldn't imply a panic I believe, see code below.


static void *sparsemap_buf __meminitdata;
static void *sparsemap_buf_end __meminitdata;

static void __init sparse_buffer_init(unsigned long size, int nid)
{
WARN_ON(sparsemap_buf); /* forgot to call sparse_buffer_fini()? */
sparsemap_buf =
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, nid);
sparsemap_buf_end = sparsemap_buf + size;
}

static void __init sparse_buffer_fini(void)
{
unsigned long size = sparsemap_buf_end - sparsemap_buf;

if (sparsemap_buf && size > 0)
memblock_free_early(__pa(sparsemap_buf), size);
sparsemap_buf = NULL;
}

void * __meminit sparse_buffer_alloc(unsigned long size)
{
void *ptr = NULL;

if (sparsemap_buf) {
ptr = PTR_ALIGN(sparsemap_buf, size);
if (ptr + size > sparsemap_buf_end)
ptr = NULL;
else
sparsemap_buf = ptr + size;
}
return ptr;
}


Christophe

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

Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

[Christophe Leroy]

Le 31/01/2019 à 07:41, Mike Rapoport a écrit :

On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:



Le 21/01/2019 à 09:04, Mike Rapoport a écrit :

Add check for the return value of memblock_alloc*() functions and call
panic() in case of error.
The panic message repeats the one used by panicing memblock allocators with
adjustment of parameters to include only relevant ones.

The replacement was mostly automated with semantic patches like the one
below with manual massaging of format strings.

@@
expression ptr, size, align;
@@
ptr = memblock_alloc(size, align);
+ if (!ptr)
+   panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
size, align);

Signed-off-by: Mike Rapoport 
Reviewed-by: Guo Ren  # c-sky
Acked-by: Paul Burton# MIPS
Acked-by: Heiko Carstens  # s390
Reviewed-by: Juergen Gross  # Xen
---


[...]


diff --git a/mm/sparse.c b/mm/sparse.c
index 7ea5dc6..ad94242 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c


[...]


@@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned long size, 
int nid)
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+   if (!sparsemap_buf)
+   panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d 
from=%lx\n",
+ __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
+


memblock_alloc_try_nid_raw() does not panic (help explicitly says: Does not
zero allocated memory, does not panic if request cannot be satisfied.).


"Does not panic" does not mean it always succeeds.


I agree, but at least here you are changing the behaviour by making it 
panic explicitly. Are we sure there are not cases where the system could 
just continue functionning ? Maybe a WARN_ON() would be enough there ?


Christophe

  

Stephen Rothwell reports a boot failure due to this change.


Please see my reply on that thread.


Christophe


sparsemap_buf_end = sparsemap_buf + size;
  }







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

Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

[Christophe Leroy]

Le 21/01/2019 à 09:04, Mike Rapoport a écrit :

Add check for the return value of memblock_alloc*() functions and call
panic() in case of error.
The panic message repeats the one used by panicing memblock allocators with
adjustment of parameters to include only relevant ones.

The replacement was mostly automated with semantic patches like the one
below with manual massaging of format strings.

@@
expression ptr, size, align;
@@
ptr = memblock_alloc(size, align);
+ if (!ptr)
+   panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
size, align);

Signed-off-by: Mike Rapoport 
Reviewed-by: Guo Ren  # c-sky
Acked-by: Paul Burton# MIPS
Acked-by: Heiko Carstens  # s390
Reviewed-by: Juergen Gross  # Xen
---


[...]


diff --git a/mm/sparse.c b/mm/sparse.c
index 7ea5dc6..ad94242 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c


[...]


@@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned long size, 
int nid)
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+   if (!sparsemap_buf)
+   panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d 
from=%lx\n",
+ __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
+


memblock_alloc_try_nid_raw() does not panic (help explicitly says: Does 
not zero allocated memory, does not panic if request cannot be satisfied.).


Stephen Rothwell reports a boot failure due to this change.

Christophe


sparsemap_buf_end = sparsemap_buf + size;
  }
  



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

Re: [PATCH 2/2] kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops

[Christophe LEROY]

Le 06/12/2018 à 15:07, Daniel Thompson a écrit :

On Wed, Dec 05, 2018 at 04:41:11AM +, Christophe Leroy wrote:

checkpatch.pl reports the following:

   WARNING: struct kgdb_arch should normally be const
   #28: FILE: arch/mips/kernel/kgdb.c:397:
   +struct kgdb_arch arch_kgdb_ops = {

This report makes sense, as all other ops struct, this
one should also be const. This patch does the change.

Signed-off-by: Christophe Leroy 


Acked-by: Daniel Thompson 

Similar to https://patchwork.kernel.org/patch/10701129/ I would be more
comfortable to see a resend with the relevant arch maintainers
explicitly called out with a Cc: entry here.


Done in v2

And
Acked-by: Paul Burton 

Thanks
Christophe





---
  arch/arc/kernel/kgdb.c| 2 +-
  arch/arm/kernel/kgdb.c| 2 +-
  arch/arm64/kernel/kgdb.c  | 2 +-
  arch/h8300/kernel/kgdb.c  | 2 +-
  arch/hexagon/kernel/kgdb.c| 2 +-
  arch/microblaze/kernel/kgdb.c | 2 +-
  arch/mips/kernel/kgdb.c   | 2 +-
  arch/nios2/kernel/kgdb.c  | 2 +-
  arch/powerpc/kernel/kgdb.c| 2 +-
  arch/sh/kernel/kgdb.c | 2 +-
  arch/sparc/kernel/kgdb_32.c   | 2 +-
  arch/sparc/kernel/kgdb_64.c   | 2 +-
  arch/x86/kernel/kgdb.c| 2 +-
  include/linux/kgdb.h  | 2 +-
  14 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
index 9a3c34af2ae8..bfd04b442e36 100644
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -204,7 +204,7 @@ void kgdb_roundup_cpus(unsigned long flags)
local_irq_disable();
  }
  
-struct kgdb_arch arch_kgdb_ops = {

+const struct kgdb_arch arch_kgdb_ops = {
/* breakpoint instruction: TRAP_S 0x3 */
  #ifdef CONFIG_CPU_BIG_ENDIAN
.gdb_bpt_instr  = {0x78, 0x7e},
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index caa0dbe3dc61..21a6d5958955 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -274,7 +274,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
   * and we handle the normal undef case within the do_undefinstr
   * handler.
   */
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
  #ifndef __ARMEB__
.gdb_bpt_instr  = {0xfe, 0xde, 0xff, 0xe7}
  #else /* ! __ARMEB__ */
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index a20de58061a8..fe1d1f935b90 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -357,7 +357,7 @@ void kgdb_arch_exit(void)
unregister_die_notifier(_notifier);
  }
  
-struct kgdb_arch arch_kgdb_ops;

+const struct kgdb_arch arch_kgdb_ops;
  
  int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)

  {
diff --git a/arch/h8300/kernel/kgdb.c b/arch/h8300/kernel/kgdb.c
index 1a1d30cb0609..602e478afbd5 100644
--- a/arch/h8300/kernel/kgdb.c
+++ b/arch/h8300/kernel/kgdb.c
@@ -129,7 +129,7 @@ void kgdb_arch_exit(void)
/* Nothing to do */
  }
  
-struct kgdb_arch arch_kgdb_ops = {

+const struct kgdb_arch arch_kgdb_ops = {
/* Breakpoint instruction: trapa #2 */
.gdb_bpt_instr = { 0x57, 0x20 },
  };
diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
index 16c24b22d0b2..f1924d483e78 100644
--- a/arch/hexagon/kernel/kgdb.c
+++ b/arch/hexagon/kernel/kgdb.c
@@ -83,7 +83,7 @@ struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
{ "syscall_nr", GDB_SIZEOF_REG, offsetof(struct pt_regs, syscall_nr)},
  };
  
-struct kgdb_arch arch_kgdb_ops = {

+const struct kgdb_arch arch_kgdb_ops = {
/* trap0(#0xDB) 0x0cdb0054 */
.gdb_bpt_instr = {0x54, 0x00, 0xdb, 0x0c},
  };
diff --git a/arch/microblaze/kernel/kgdb.c b/arch/microblaze/kernel/kgdb.c
index 6366f69d118e..130cd0f064ce 100644
--- a/arch/microblaze/kernel/kgdb.c
+++ b/arch/microblaze/kernel/kgdb.c
@@ -143,7 +143,7 @@ void kgdb_arch_exit(void)
  /*
   * Global data
   */
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
  #ifdef __MICROBLAZEEL__
.gdb_bpt_instr = {0x18, 0x00, 0x0c, 0xba}, /* brki r16, 0x18 */
  #else
diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
index 31eff1bec577..edfdc2ec2d16 100644
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -394,7 +394,7 @@ int kgdb_arch_handle_exception(int vector, int signo, int 
err_code,
return -1;
  }
  
-struct kgdb_arch arch_kgdb_ops = {

+const struct kgdb_arch arch_kgdb_ops = {
  #ifdef CONFIG_CPU_BIG_ENDIAN
.gdb_bpt_instr = { spec_op << 2, 0x00, 0x00, break_op },
  #else
diff --git a/arch/nios2/kernel/kgdb.c b/arch/nios2/kernel/kgdb.c
index 117859122d1c..37b25f844a2d 100644
--- a/arch/nios2/kernel/kgdb.c
+++ b/arch/nios2/kernel/kgdb.c
@@ -165,7 +165,7 @@ void kgdb_arch_exit(void)
/* Nothing to do */
  }
  
-struct kgdb_arch arch_kgdb_ops = {

+const struct kgdb_arch arch_kgdb_ops = {
/* Breakpoint instruction: trap 30 */
.gdb_bpt_instr = { 0xba, 0x6f, 0x3b, 0x00 },
  };
diff --git a/arch/powerpc/kern