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

[Michael Ellerman]

Arnd Bergmann  writes:
> 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.
>
> Reviewed-by: Christophe Leroy  (powerpc32)
> Acked-by: Catalin Marinas 
> Acked-by: Helge Deller  # parisc
> Signed-off-by: Arnd Bergmann 
> ---
> No changes from v1
>
>  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(-)

Acked-by: Michael Ellerman  (powerpc)

cheers

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

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

[Michael Ellerman]

Hi Arnd,

Arnd Bergmann  writes:
> 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 
> ---
> Changes from v1:
>  - improve Kconfig help texts
>  - fix Hexagon Kconfig
>
>  arch/Kconfig  | 92 ++-
>  arch/hexagon/Kconfig  | 24 ++--
>  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, 121 insertions(+), 161 deletions(-)

There's a few "help" lines missing, which breaks the build:

  arch/Kconfig:1134: syntax error
  arch/Kconfig:1133: invalid statement
  arch/Kconfig:1134: invalid statement
  arch/Kconfig:1135:warning: ignoring unsupported character '.'
  arch/Kconfig:1135:warning: ignoring unsupported character '.'
  arch/Kconfig:1135: invalid statement
  arch/Kconfig:1136: invalid statement
  arch/Kconfig:1137:warning: ignoring unsupported character '.'
  arch/Kconfig:1137: invalid statement
  arch/Kconfig:1143: syntax error
  arch/Kconfig:1142: invalid statement
  arch/Kconfig:1143: invalid statement
  arch/Kconfig:1144:warning: ignoring unsupported character '.'
  arch/Kconfig:1144: invalid statement
  arch/Kconfig:1145: invalid statement
  arch/Kconfig:1146: invalid statement
  arch/Kconfig:1147: invalid statement
  arch/Kconfig:1148:warning: ignoring unsupported character '.'
  arch/Kconfig:1148: invalid statement
  make[4]: *** [../scripts/kconfig/Makefile:85: syncconfig] Error 1

Fixup diff is:

diff --git a/arch/Kconfig b/arch/Kconfig
index 56d45a75f625..f2295fa3b48c 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1130,6 +1130,7 @@ config PAGE_SIZE_16KB
 config PAGE_SIZE_32KB
bool "32KiB pages"
depends on HAVE_PAGE_SIZE_32KB
+   help
  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.
@@ -1139,6 +1140,7 @@ config PAGE_SIZE_32KB
 config PAGE_SIZE_64KB
bool "64KiB pages"
depends on HAVE_PAGE_SIZE_64KB
+   help
  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.


cheers

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

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

[Michael Ellerman]

Christophe Leroy  writes:
> 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/

Yeah, and that patch would silently conflict with this series, which is
not ideal.

I could delay merging my patch above until after this series goes in,
mine only fixes a fairly obscure build warning.

cheers

___
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

[Michael Ellerman]

Christophe Leroy  writes:
> 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

[Michael Ellerman]

"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;

Re: [PATCH] treewide: drop CONFIG_EMBEDDED

[Michael Ellerman]

Randy Dunlap  writes:
> There is only one Kconfig user of CONFIG_EMBEDDED and it can be
> switched to EXPERT or "if !ARCH_MULTIPLATFORM" (suggested by Arnd).
>
> Signed-off-by: Randy Dunlap 
...
>  arch/powerpc/configs/40x/klondike_defconfig  |2 +-
>  arch/powerpc/configs/44x/fsp2_defconfig  |2 +-
>  arch/powerpc/configs/52xx/tqm5200_defconfig  |2 +-
>  arch/powerpc/configs/mgcoge_defconfig|2 +-
>  arch/powerpc/configs/microwatt_defconfig |2 +-
>  arch/powerpc/configs/ps3_defconfig       |2 +-
  
Acked-by: Michael Ellerman  (powerpc)

...

> diff -- a/init/Kconfig b/init/Kconfig
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1790,14 +1790,6 @@ config DEBUG_RSEQ
>  
> If unsure, say N.
>  
> -config EMBEDDED
> - bool "Embedded system"
> - select EXPERT

This is a crucial detail that could be mentioned in the change log. ie.
that all defconfigs that currently have EMBEDDED=y are currently
selecting EXPERT already.

cheers

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

Re: [PATCH v2 15/19] arch/powerpc: Implement with generic helpers

[Michael Ellerman]

Thomas Zimmermann  writes:
> Replace the architecture's fb_is_primary_device() with the generic
> one from . No functional changes.
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Michael Ellerman 
> Cc: Nicholas Piggin 
> Cc: Christophe Leroy 
> ---
>  arch/powerpc/include/asm/fb.h | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)

Looks fine.

Acked-by: Michael Ellerman  (powerpc)

cheers

> diff --git a/arch/powerpc/include/asm/fb.h b/arch/powerpc/include/asm/fb.h
> index 6541ab77c5b9..5f1a2e5f7654 100644
> --- a/arch/powerpc/include/asm/fb.h
> +++ b/arch/powerpc/include/asm/fb.h
> @@ -2,8 +2,8 @@
>  #ifndef _ASM_FB_H_
>  #define _ASM_FB_H_
>  
> -#include 
>  #include 
> +
>  #include 
>  
>  static inline void fb_pgprotect(struct file *file, struct vm_area_struct 
> *vma,
> @@ -13,10 +13,8 @@ static inline void fb_pgprotect(struct file *file, struct 
> vm_area_struct *vma,
>vma->vm_end - vma->vm_start,
>vma->vm_page_prot);
>  }
> +#define fb_pgprotect fb_pgprotect
>  
> -static inline int fb_is_primary_device(struct fb_info *info)
> -{
> - return 0;
> -}
> +#include 
>  
>  #endif /* _ASM_FB_H_ */
> -- 
> 2.40.0

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

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

[Michael Ellerman]

Rick Edgecombe  writes:
> 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.
...
> ---
> 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.
...
> ---
>  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 +-

Looks like you discovered the joys of ppc's at-least 5 different MMU
implementations, sorry :)

Acked-by: Michael Ellerman  (powerpc)

cheers

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

Re: [PATCH v3 09/24] powerpc: Remove COMMAND_LINE_SIZE from uapi

[Michael Ellerman]

Alexandre Ghiti  writes:
> From: Palmer Dabbelt 
>
> As far as I can tell this is not used by userspace and thus should not
> be part of the user-visible API.
>
> Signed-off-by: Palmer Dabbelt 
> ---
>  arch/powerpc/include/asm/setup.h  | 2 +-
>  arch/powerpc/include/uapi/asm/setup.h | 2 --
>  2 files changed, 1 insertion(+), 3 deletions(-)

Acked-by: Michael Ellerman  (powerpc)

cheers

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

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

[Michael Ellerman]

David Hildenbrand  writes:
> 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(-)

I gave this a quick test on a ppc32 machine, everything seems fine.

Your test_swp_exclusive.c passes, and an LTP run looks normal.

Acked-by: Michael Ellerman  (powerpc)

cheers

> diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h 
> b/arch/powerpc/include/asm/book3s/32/pgtable.h
> index 75823f39e042..0ecb3a58f23f 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
> + *   <- offset > < type -> E H P
> + *
> + *   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; }
> -- 
> 2.39.0
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

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

Re: [PATCH v2 4/4] mm, arch: add generic implementation of pfn_valid() for FLATMEM

[Michael Ellerman]

Mike Rapoport  writes:
> From: "Mike Rapoport (IBM)" 
>
> Every architecture that supports FLATMEM memory model defines its own
> version of pfn_valid() that essentially compares a pfn to max_mapnr.
>
> Use mips/powerpc version implemented as static inline as a generic
> implementation of pfn_valid() and drop its per-architecture definitions.
>
> Signed-off-by: Mike Rapoport (IBM) 
> Acked-by: Arnd Bergmann 
> Acked-by: Guo Ren  # csky
> Acked-by: Huacai Chen # LoongArch
> Acked-by: Stafford Horne# OpenRISC
> ---
>  arch/alpha/include/asm/page.h  |  4 
>  arch/arc/include/asm/page.h|  1 -
>  arch/csky/include/asm/page.h   |  1 -
>  arch/hexagon/include/asm/page.h|  1 -
>  arch/ia64/include/asm/page.h   |  4 
>  arch/loongarch/include/asm/page.h  | 13 -
>  arch/m68k/include/asm/page_no.h|  2 --
>  arch/microblaze/include/asm/page.h |  1 -
>  arch/mips/include/asm/page.h   | 13 -
>  arch/nios2/include/asm/page.h  |  9 -
>  arch/openrisc/include/asm/page.h   |  2 --
>  arch/parisc/include/asm/page.h |  4 
>  arch/powerpc/include/asm/page.h|  9 -

Acked-by: Michael Ellerman  (powerpc)

cheers

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

Re: [PATCH] arch: mm: rename FORCE_MAX_ZONEORDER to ARCH_FORCE_MAX_ORDER

[Michael Ellerman]

Zi Yan  writes:
> From: Zi Yan 
>
> This Kconfig option is used by individual arch to set its desired
> MAX_ORDER. Rename it to reflect its actual use.
>
> Acked-by: Mike Rapoport 
> Signed-off-by: Zi Yan 
...
>  arch/powerpc/Kconfig | 2 +-
>  arch/powerpc/configs/85xx/ge_imp3a_defconfig | 2 +-
>  arch/powerpc/configs/fsl-emb-nonhw.config| 2 +-

Acked-by: Michael Ellerman  (powerpc)

cheers

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

Re: [PATCH V3 04/30] powerpc/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT

[Michael Ellerman]

Anshuman Khandual  writes:
> 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. While here, this also
> localizes arch_vm_get_page_prot() as powerpc_vm_get_page_prot() and moves
> it near vm_get_page_prot().
>
> Cc: Michael Ellerman 
> Cc: Paul Mackerras 
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 
> ---
>  arch/powerpc/Kconfig   |  1 +
>  arch/powerpc/include/asm/mman.h| 12 --
>  arch/powerpc/include/asm/pgtable.h | 19 --
>  arch/powerpc/mm/mmap.c | 59 ++
>  4 files changed, 60 insertions(+), 31 deletions(-)

Acked-by: Michael Ellerman  (powerpc)

cheers

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

Re: [PATCH -next] trap: Cleanup trap_init()

[Michael Ellerman]

Kefeng Wang  writes:
> There are some empty trap_init() in different ARCHs, introduce
> a new weak trap_init() function to cleanup them.
>
> Cc: Vineet Gupta 
> Cc: Russell King 
> Cc: Yoshinori Sato 
> Cc: Ley Foon Tan 
> Cc: Jonas Bonn 
> Cc: Stefan Kristiansson 
> Cc: Stafford Horne 
> Cc: James E.J. Bottomley 
> Cc: Helge Deller 
> Cc: Michael Ellerman 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Paul Walmsley 
> Cc: Jeff Dike 
> Cc: Richard Weinberger 
> Cc: Anton Ivanov 
> Cc: Andrew Morton 
> Signed-off-by: Kefeng Wang 
> ---
>  arch/arc/kernel/traps.c  | 5 -
>  arch/arm/kernel/traps.c  | 5 -
>  arch/h8300/kernel/traps.c| 4 
>  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 -

Acked-by: Michael Ellerman  (powerpc)

cheers

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

Re: [PATCH 2/3] trace: refactor TRACE_IRQFLAGS_SUPPORT in Kconfig

[Michael Ellerman]

Masahiro Yamada  writes:
> Make architectures select TRACE_IRQFLAGS_SUPPORT instead of
> having many defines.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/Kconfig  | 3 +++
>  arch/arc/Kconfig  | 4 +---
>  arch/arm/Kconfig  | 5 +
>  arch/arm64/Kconfig| 4 +---
>  arch/csky/Kconfig | 4 +---
>  arch/hexagon/Kconfig  | 4 +---
>  arch/microblaze/Kconfig   | 1 +
>  arch/microblaze/Kconfig.debug | 5 -
>  arch/mips/Kconfig | 1 +
>  arch/mips/Kconfig.debug   | 4 
>  arch/nds32/Kconfig| 4 +---
>  arch/nios2/Kconfig| 3 ---
>  arch/openrisc/Kconfig | 4 +---
>  arch/parisc/Kconfig   | 1 +
>  arch/parisc/Kconfig.debug | 3 ---
>  arch/powerpc/Kconfig  | 5 +
>  arch/riscv/Kconfig| 4 +---
>  arch/s390/Kconfig | 1 +
>  arch/s390/Kconfig.debug   | 3 ---
>  arch/sh/Kconfig   | 1 +
>  arch/sh/Kconfig.debug | 3 ---
>  arch/sparc/Kconfig| 1 +
>  arch/sparc/Kconfig.debug  | 4 
>  arch/um/Kconfig   | 5 +
>  arch/x86/Kconfig  | 1 +
>  arch/x86/Kconfig.debug| 3 ---
>  arch/xtensa/Kconfig   | 4 +---
>  27 files changed, 21 insertions(+), 64 deletions(-)

> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index d01e3401581d..76a28452c042 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -94,10 +94,6 @@ config STACKTRACE_SUPPORT
>   bool
>   default y
>  
> -config TRACE_IRQFLAGS_SUPPORT
> - bool
> - default y
> -
>  config LOCKDEP_SUPPORT
>   bool
>   default y
> @@ -271,6 +267,7 @@ config PPC
>   select STRICT_KERNEL_RWX if STRICT_MODULE_RWX
>   select SYSCTL_EXCEPTION_TRACE
>   select THREAD_INFO_IN_TASK
> + select TRACE_IRQFLAGS_SUPPORT
>   select VIRT_TO_BUS  if !PPC64
>   #
>   # Please keep this list sorted alphabetically.

Acked-by: Michael Ellerman  (powerpc)

cheers

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

Re: [PATCH 0/2] Change struct page layout for page_pool

[Michael Ellerman]

"Matthew Wilcox (Oracle)"  writes:
> The first patch here fixes two bugs on ppc32, and mips32.  It fixes one
> bug on arc and arm32 (in certain configurations).  It probably makes
> sense to get it in ASAP through the networking tree.  I'd like to see
> testing on those four architectures if possible?

Sorry I don't have easy access to any hardware that fits the bill. At
some point I'll be able to go to the office and setup a machine that (I
think) can test these paths, but I don't have an ETA on that.

You and others seem to have done lots of analysis on this though, so I
think you should merge the fixes without waiting on ppc32 testing.

cheers


>
> The second patch enables new functionality.  It is much less urgent.
> I'd really like to see Mel & Michal's thoughts on it.
>
> I have only compile-tested these patches.
>
> Matthew Wilcox (Oracle) (2):
>   mm: Fix struct page layout on 32-bit systems
>   mm: Indicate pfmemalloc pages in compound_head
>
>  include/linux/mm.h   | 12 +++-
>  include/linux/mm_types.h |  9 -
>  include/net/page_pool.h  | 12 +++-
>  net/core/page_pool.c | 12 +++-
>  4 files changed, 29 insertions(+), 16 deletions(-)
>
> -- 
> 2.30.2

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

Re: [PATCH 2/6] mm: Generalize SYS_SUPPORTS_HUGETLBFS (rename as ARCH_SUPPORTS_HUGETLBFS)

[Michael Ellerman]

Anshuman Khandual  writes:
> SYS_SUPPORTS_HUGETLBFS config has duplicate definitions on platforms that
> subscribe it. Instead, just make it a generic option which can be selected
> on applicable platforms. Also rename it as ARCH_SUPPORTS_HUGETLBFS instead.
> This reduces code duplication and makes it cleaner.
>
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Thomas Bogendoerfer 
> Cc: "James E.J. Bottomley" 
> Cc: Helge Deller 
> Cc: Michael Ellerman 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Paul Walmsley 
> Cc: Palmer Dabbelt 
> Cc: Albert Ou 
> Cc: Yoshinori Sato 
> Cc: Rich Felker 
> Cc: Alexander Viro 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-m...@vger.kernel.org
> Cc: linux-par...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-ri...@lists.infradead.org
> Cc: linux...@vger.kernel.org
> Cc: linux-fsde...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 
> ---
>  arch/arm/Kconfig   | 5 +
>  arch/arm64/Kconfig | 4 +---
>  arch/mips/Kconfig  | 6 +-
>  arch/parisc/Kconfig| 5 +
>  arch/powerpc/Kconfig   | 3 ---
>  arch/powerpc/platforms/Kconfig.cputype | 6 +++---

Acked-by: Michael Ellerman  (powerpc)

cheers

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

Re: [PATCH v3 2/5] powerpc: module_[32|64].c: replace swap function with built-in one

[Michael Ellerman]

On Tue, 2019-04-02 at 20:47:22 UTC, Andrey Abramov wrote:
> Replace relaswap with built-in one, because relaswap
> does a simple byte to byte swap.
> 
> Since Spectre mitigations have made indirect function calls more
> expensive, and the default simple byte copies swap is implemented
> without them, an "optimized" custom swap function is now
> a waste of time as well as code.
> 
> Signed-off-by: Andrey Abramov 
> Reviewed by: George Spelvin 
> Acked-by: Michael Ellerman  (powerpc)

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/bac7ca7b985b72873bd4ac2553b13b5af5b1f08a

cheers

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

Re: [PATCH V1 00/10] Remove duplicated kmap code

[Michael Ellerman]

ira.we...@intel.com writes:
> From: Ira Weiny 
>
> The kmap infrastructure has been copied almost verbatim to every architecture.
> This series consolidates obvious duplicated code by defining core functions
> which call into the architectures only when needed.
>
> Some of the k[un]map_atomic() implementations have some similarities but the
> similarities were not sufficient to warrant further changes.
>
> In addition we remove a duplicate implementation of kmap() in DRM.
>
> Testing was done by 0day to cover all the architectures I can't readily
> build/test.

I threw some powerpc builds at it and they all passed, so LGTM.

cheers

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

Re: [RESEND PATCH v2 1/9] iomap: Constify ioreadX() iomem argument (as in generic implementation)

[Michael Ellerman]

Krzysztof Kozlowski  writes:
> diff --git a/arch/powerpc/kernel/iomap.c b/arch/powerpc/kernel/iomap.c
> index 5ac84efc6ede..9fe4fb3b08aa 100644
> --- a/arch/powerpc/kernel/iomap.c
> +++ b/arch/powerpc/kernel/iomap.c
> @@ -15,23 +15,23 @@
>   * Here comes the ppc64 implementation of the IOMAP 
>   * interfaces.
>   */
> -unsigned int ioread8(void __iomem *addr)
> +unsigned int ioread8(const void __iomem *addr)
>  {
>   return readb(addr);
>  }
> -unsigned int ioread16(void __iomem *addr)
> +unsigned int ioread16(const void __iomem *addr)
>  {
>   return readw(addr);
>  }
> -unsigned int ioread16be(void __iomem *addr)
> +unsigned int ioread16be(const void __iomem *addr)
>  {
>   return readw_be(addr);
>  }
> -unsigned int ioread32(void __iomem *addr)
> +unsigned int ioread32(const void __iomem *addr)
>  {
>   return readl(addr);
>  }
> -unsigned int ioread32be(void __iomem *addr)
> +unsigned int ioread32be(const void __iomem *addr)
>  {
>   return readl_be(addr);
>  }
> @@ -41,27 +41,27 @@ EXPORT_SYMBOL(ioread16be);
>  EXPORT_SYMBOL(ioread32);
>  EXPORT_SYMBOL(ioread32be);
>  #ifdef __powerpc64__
> -u64 ioread64(void __iomem *addr)
> +u64 ioread64(const void __iomem *addr)
>  {
>   return readq(addr);
>  }
> -u64 ioread64_lo_hi(void __iomem *addr)
> +u64 ioread64_lo_hi(const void __iomem *addr)
>  {
>   return readq(addr);
>  }
> -u64 ioread64_hi_lo(void __iomem *addr)
> +u64 ioread64_hi_lo(const void __iomem *addr)
>  {
>   return readq(addr);
>  }
> -u64 ioread64be(void __iomem *addr)
> +u64 ioread64be(const void __iomem *addr)
>  {
>   return readq_be(addr);
>  }
> -u64 ioread64be_lo_hi(void __iomem *addr)
> +u64 ioread64be_lo_hi(const void __iomem *addr)
>  {
>   return readq_be(addr);
>  }
> -u64 ioread64be_hi_lo(void __iomem *addr)
> +u64 ioread64be_hi_lo(const void __iomem *addr)
>  {
>   return readq_be(addr);
>  }
> @@ -139,15 +139,15 @@ EXPORT_SYMBOL(iowrite64be_hi_lo);
>   * FIXME! We could make these do EEH handling if we really
>   * wanted. Not clear if we do.
>   */
> -void ioread8_rep(void __iomem *addr, void *dst, unsigned long count)
> +void ioread8_rep(const void __iomem *addr, void *dst, unsigned long count)
>  {
>   readsb(addr, dst, count);
>  }
> -void ioread16_rep(void __iomem *addr, void *dst, unsigned long count)
> +void ioread16_rep(const void __iomem *addr, void *dst, unsigned long count)
>  {
>   readsw(addr, dst, count);
>  }
> -void ioread32_rep(void __iomem *addr, void *dst, unsigned long count)
> +void ioread32_rep(const void __iomem *addr, void *dst, unsigned long count)
>  {
>   readsl(addr, dst, count);
>  }

This looks OK to me.

Acked-by: Michael Ellerman  (powerpc)

cheers

___
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

[Michael Ellerman]

Anshuman Khandual  writes:
> On 11/06/2019 12:11 PM, Christophe Leroy wrote:
>> 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.
>
> Right, I understand. But we are yet to hear about how this test
> came about on powerpc server platforms. Will update 'powerpc'
> arch listing above once we get some confirmation. May be once
> this works on all relevant powerpc platforms, we can just merge
> 'powerpc' and 'ppc32' entries here as just 'powerpc'.

On pseries:

  watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:1]
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
5.4.0-rc6-gcc-8.2.0-next-20191107-1-g250339d6747b-dirty #152
  NIP:  c10435a0 LR: c10434b4 CTR: 
  REGS: c0003a403980 TRAP: 0901   Not tainted  
(5.4.0-rc6-gcc-8.2.0-next-20191107-1-g250339d6747b-dirty)
  MSR:  82009033   CR: 44000222  XER: 
  CFAR: c10435a8 IRQMASK: 0 
  GPR00: c10434b4 c0003a403c10 c1295000 0521000100c0 
  GPR04: 8105 00400dc0 3eb0 0001 
  GPR08:   0001 0100 
  GPR12:  c18f 
  NIP [c10435a0] debug_vm_pgtable+0x43c/0x82c
  LR [c10434b4] debug_vm_pgtable+0x350/0x82c
  Call Trace:
  [c0003a403c10] [c104346c] debug_vm_pgtable+0x308/0x82c 
(unreliable)
  [c0003a403ce0] [c1004310] kernel_init_freeable+0x1d0/0x39c
  [c0003a403db0] [c0010da0] kernel_init+0x24/0x174
  [c0003a403e20] [c000bdc4] ret_from_kernel_thread+0x5c/0x78
  Instruction dump:
  7d075078 7ce74b78 7ce0f9ad 40c2fff0 3880 7f83e378 4b02eee1 6000 
  4880 3920 3941 3900 <7ea0f8a8> 7ea75039 40c2fff8 7ea74878 

Looking at the asm I think it's stuck in hash__pte_update() waiting for
H_PAGE_BUSY to clear, but not sure why.

That's just using qemu TCG, instructions here if anyone wants to test it
themselves :)

  https://github.com/linuxppc/wiki/wiki/Booting-with-Qemu


If I boot with -cpu power9 (using Radix MMU), I get a plain old BUG:

  debug_vm_pgtable: debug_vm_pgtable: Validating architecture page table helpers
  [ cut here ]
  kernel BUG at arch/powerpc/mm/pgtable.c:274!
  Oops: Exception in kernel mode, sig: 5 [#1]
  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=32 NUMA pSeries
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
5.4.0-rc6-gcc-8.2.0-next-20191107-1-g250339d6747b-dirty #152
  NIP:  c00724e8 LR: c104358c CTR: 
  REGS: c0003a483980 TRAP: 0700   Not tainted  
(5.4.0-rc6-gcc-8.2.0-next-20191107-1-g250339d6747b-dirty)
  MSR:  82029033   CR: 24000224  XER: 2000
  CFAR: c1043588 IRQMASK: 0 
  GPR00: c104358c c0003a483c10 c1295000 0009 
  GPR04:  0005  0009 
  GPR08: 0001 000e 0001 c0003a5f 
  GPR12:  c18f c0010d84  
  GPR16:   c0003a5f 8105 
  GPR20: c1003ab8 0015 0500613a0080 0900603a0080 
  GPR24: 09202e3a0080 c133bd90 c133bd98 c133bda0 
  GPR28: c0003a5e c0003a600af8 c0003a2e2d48 c0003a6100a0 
  NIP [c00724e8] assert_pte_locked+0x88/0x190
  LR [c104358c] debug_vm_pgtable+0x428/0x82c
  Call Trace:
  [c0003a483c10] [c104346c] debug_vm_pgtable+0x308/0x82c 
(unreliable)
  [c0003a483ce0] [c1004310] kernel_init_freeable+0x1d0/0x39c
  [c0003a483db0] [c0010da0] kernel_init+0x24/0x174
  [c0003a483e20] [c000bdc4] ret_from_kernel_thread+0x5c/0x78
  Instruction dump:
  7d251a14 39070010 7d463030 7d084a14 38c6 7c884436 7cc607b4 7d083038 
  79081f24 7ccb402a 7cc80074 7908d182 <0b08> 78cb0022 54c8c03e 7d473830 
  ---[ end trace a694f1bc56529c0e ]---


cheers
___
linux-snps-arc mailing list

Re: [PATCH v2 2/5] powerpc: module_[32|64].c: replace swap function with built-in one

[Michael Ellerman]

Andrey Abramov  writes:
> Replace relaswap with built-in one, because relaswap
> does a simple byte to byte swap.

I replied to v1 with an ack, which stands, this is just a clarification.

> Since Spectre mitigations have made indirect function calls more
> expensive, and the default simple byte copies swap is implemented
> without them, an "optimized" custom swap function is now
> a waste of time as well as code.

Spectre mitigations don't necessarily slow down indirect function calls
on all arches or in all configurations on all arches, so that
justification is a bit dubious.

That's not really a problem for this patch, because the existing
overhead of the function call is probably already enough to rival the
cost of the 24 byte copy.

cheers

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

Re: [PATCH v2 10/21] memblock: refactor internal allocation functions

[Michael Ellerman]

Mike Rapoport  writes:

> Currently, memblock has several internal functions with overlapping
> functionality. They all call memblock_find_in_range_node() to find free
> memory and then reserve the allocated range and mark it with kmemleak.
> However, there is difference in the allocation constraints and in fallback
> strategies.
>
> The allocations returning physical address first attempt to find free
> memory on the specified node within mirrored memory regions, then retry on
> the same node without the requirement for memory mirroring and finally fall
> back to all available memory.
>
> The allocations returning virtual address start with clamping the allowed
> range to memblock.current_limit, attempt to allocate from the specified
> node from regions with mirroring and with user defined minimal address. If
> such allocation fails, next attempt is done with node restriction lifted.
> Next, the allocation is retried with minimal address reset to zero and at
> last without the requirement for mirrored regions.
>
> Let's consolidate various fallbacks handling and make them more consistent
> for physical and virtual variants. Most of the fallback handling is moved
> to memblock_alloc_range_nid() and it now handles node and mirror fallbacks.
>
> The memblock_alloc_internal() uses memblock_alloc_range_nid() to get a
> physical address of the allocated range and converts it to virtual address.
>
> The fallback for allocation below the specified minimal address remains in
> memblock_alloc_internal() because memblock_alloc_range_nid() is used by CMA
> with exact requirement for lower bounds.

This is causing problems on some of my machines.

I see NODE_DATA allocations falling back to node 0 when they shouldn't,
or didn't previously.

eg, before:

57990190: (116011251): numa:   NODE_DATA [mem 0xfffe4980-0xfffebfff]
58152042: (116373087): numa:   NODE_DATA [mem 0x8fff90980-0x8fff97fff]

after:

16356872061562: (6296877055): numa:   NODE_DATA [mem 0xfffe4980-0xfffebfff]
16356872079279: (6296894772): numa:   NODE_DATA [mem 0xfffcd300-0xfffd497f]
16356872096376: (6296911869): numa: NODE_DATA(1) on node 0


On some of my other systems it does that, and then panics because it
can't allocate anything at all:

[0.00] numa:   NODE_DATA [mem 0x7ffcaee80-0x7ffcb3fff]
[0.00] numa:   NODE_DATA [mem 0x7ffc99d00-0x7ffc9ee7f]
[0.00] numa: NODE_DATA(1) on node 0
[0.00] Kernel panic - not syncing: Cannot allocate 20864 bytes for node 
16 data
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
5.0.0-rc4-gccN-next-20190201-gdc4c899 #1
[0.00] Call Trace:
[0.00] [c11cfca0] [c0c11044] dump_stack+0xe8/0x164 
(unreliable)
[0.00] [c11cfcf0] [c00fdd6c] panic+0x17c/0x3e0
[0.00] [c11cfd90] [c0f61bc8] initmem_init+0x128/0x260
[0.00] [c11cfe60] [c0f57940] setup_arch+0x398/0x418
[0.00] [c11cfee0] [c0f50a94] start_kernel+0xa0/0x684
[0.00] [c11cff90] [c000af70] 
start_here_common+0x1c/0x52c
[0.00] Rebooting in 180 seconds..


So there's something going wrong there, I haven't had time to dig into
it though (Sunday night here).

cheers

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

Re: [PATCH v2 09/21] memblock: drop memblock_alloc_base()

[Michael Ellerman]

Mike Rapoport  writes:

> The memblock_alloc_base() function tries to allocate a memory up to the
> limit specified by its max_addr parameter and panics if the allocation
> fails. Replace its usage with memblock_phys_alloc_range() and make the
> callers check the return value and panic in case of error.
>
> Signed-off-by: Mike Rapoport 
> ---
>  arch/powerpc/kernel/rtas.c  |  6 +-
>  arch/powerpc/mm/hash_utils_64.c |  8 ++--
>  arch/s390/kernel/smp.c  |  6 +-
>  drivers/macintosh/smu.c |  2 +-
>  include/linux/memblock.h|  2 --
>  mm/memblock.c   | 14 --
>  6 files changed, 17 insertions(+), 21 deletions(-)

Acked-by: Michael Ellerman  (powerpc)

cheers

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

Re: [PATCH v2 06/21] memblock: memblock_phys_alloc_try_nid(): don't panic

[Michael Ellerman]

Michael Ellerman  writes:

> Mike Rapoport  writes:
>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index ae34e3a..2c61ea4 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -237,6 +237,10 @@ static void __init setup_node_data(int nid, u64 
>> start_pfn, u64 end_pfn)
>>  pr_info("Initmem setup node %d []\n", nid);
>>  
>>  nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
>> +if (!nd_pa)
>> +panic("Cannot allocate %zu bytes for node %d data\n",
>> +      nd_size, nid);
>> +
>>  nd = __va(nd_pa);

Wrong hunk, O_o

> Acked-by: Michael Ellerman  (powerpc)

You know what I mean though :)

cheers

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

Re: [PATCH v2 06/21] memblock: memblock_phys_alloc_try_nid(): don't panic

[Michael Ellerman]

Mike Rapoport  writes:

> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index ae34e3a..2c61ea4 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -237,6 +237,10 @@ static void __init setup_node_data(int nid, u64 
> start_pfn, u64 end_pfn)
>   pr_info("Initmem setup node %d []\n", nid);
>  
>   nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
> + if (!nd_pa)
> + panic("Cannot allocate %zu bytes for node %d data\n",
> +   nd_size, nid);
> +
>   nd = __va(nd_pa);

Acked-by: Michael Ellerman  (powerpc)

cheers

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

Re: [PATCH v2 02/21] powerpc: use memblock functions returning virtual address

[Michael Ellerman]

Mike Rapoport  writes:

> From: Christophe Leroy 
>
> Since only the virtual address of allocated blocks is used,
> lets use functions returning directly virtual address.
>
> Those functions have the advantage of also zeroing the block.
>
> [ MR:
>  - updated error message in alloc_stack() to be more verbose
>  - convereted several additional call sites ]
>
> Signed-off-by: Christophe Leroy 
> Signed-off-by: Mike Rapoport 
> ---
>  arch/powerpc/kernel/dt_cpu_ftrs.c |  3 +--
>  arch/powerpc/kernel/irq.c |  5 -
>  arch/powerpc/kernel/paca.c|  6 +-
>  arch/powerpc/kernel/prom.c|  5 -
>  arch/powerpc/kernel/setup_32.c| 26 --
>  5 files changed, 26 insertions(+), 19 deletions(-)

LGTM.

Acked-by: Michael Ellerman 

cheers

___
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] kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops

[Michael Ellerman]

Christophe Leroy  writes:

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

> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index 59c578f865aa..bdb588b1d8fb 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -477,7 +477,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
>  /*
>   * Global data
>   */
> -struct kgdb_arch arch_kgdb_ops;
> +const struct kgdb_arch arch_kgdb_ops;
>  
>  static int kgdb_not_implemented(struct pt_regs *regs)
>  {

Acked-by: Michael Ellerman  (powerpc)

cheers

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

Re: [PATCH v2 16/15] syscall_get_arch: add "struct task_struct *" argument

[Michael Ellerman]

"Dmitry V. Levin"  writes:

> diff --git a/arch/powerpc/include/asm/syscall.h 
> b/arch/powerpc/include/asm/syscall.h
> index ab9f3f0a8637..d88b34179118 100644
> --- a/arch/powerpc/include/asm/syscall.h
> +++ b/arch/powerpc/include/asm/syscall.h
> @@ -100,9 +100,15 @@ static inline void syscall_set_arguments(struct 
> task_struct *task,
>   regs->orig_gpr3 = args[0];
>  }
>  
> -static inline int syscall_get_arch(void)
> +static inline int syscall_get_arch(struct task_struct *task)
>  {
> - int arch = is_32bit_task() ? AUDIT_ARCH_PPC : AUDIT_ARCH_PPC64;
> + int arch;
> +
> + if (IS_ENABLED(CONFIG_PPC64) && !test_tsk_thread_flag(task, TIF_32BIT))
> + arch = AUDIT_ARCH_PPC64;
> + else
> + arch = AUDIT_ARCH_PPC;
> +
>  #ifdef __LITTLE_ENDIAN__
>   arch |= __AUDIT_ARCH_LE;
>  #endif

LGTM.

Acked-by: Michael Ellerman  (powerpc)

cheers


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

Re: [PATCH] fix double ;;s in code

[Michael Ellerman]

Daniel Vetter  writes:
> On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote:
>> Le 17/02/2018 à 22:19, Pavel Machek a écrit :
>> > 
>> > Fix double ;;'s in code.
>> > 
>> > Signed-off-by: Pavel Machek 
>> 
>> A summary of the files modified on top of the patch would help understand
>> the impact.
>> 
>> A maybe there should be one patch by area, eg one for each arch specific
>> modif and one for drivers/ and one for block/ ?
>
> Yeah, pls split this into one patch per area, with a suitable patch
> subject prefix. Look at git log of each file to get a feeling for what's
> the standard in each area.

This part is actually pretty annoying.

I hacked up a script (below) which seems to do a reasonable job in most
cases.

For this patch it gives:

  $ for f in $(git ls-files -m); do ./guess-prefix.py $f; done
  ARC: 
  ARC: 
  ARM: 
  arm64: ptrace: 
  KVM: PPC: 
  powerpc/powernv:
  x86/efi:
  block/sed-opal:
  clocksource: mips-gic: 
  clocksource/drivers/sun5i:
  drm/amd/display:
  drm/amd/powerplay:
  drm/msm/mdp5:
  drm: 
  iommu/vt-d:
  md: 
  soc: imx: gpc: 

I think those are correct except for:
 - "drm:" for "drivers/gpu/drm/scheduler" which has only a single commit.
 - "md:" for "drivers/md/raid1.c" which is tricked by inconsistent
usage of "md: raid1:" and "md/raid1:".

But that seems like a reasonable hit rate.

Another approach would be to have a file that defines for each subsystem
what the preferred style is, but that is likely to be a PITA to
maintain.

cheers


#!/usr/bin/python3

import sys
import re
from subprocess import check_output
from collections import Counter

if len(sys.argv) != 2:
print('Usage: %s ' % sys.argv[0], file=sys.stderr)
sys.exit(1)

fname = sys.argv[1]

cmd = ['git', 'log', '--format=%s', '-n', '100', fname]
output = check_output(cmd).decode('utf-8')

ignore = ['License', 'Merge']

# Ordered list of patterns
patterns = [
# Common style "foo/bar/baz: Fix the foo"
re.compile('^([\w\-_]+: )+'),
# Less common "foo bar baz: Fix the foo"
re.compile('^([\w\-_]+:? )+: ')
]

words = []
for line in output.splitlines():
prefix = line.split()[0]
for patt in patterns:
match = patt.search(line)
if match:
prefix = match.group(0)
break

if prefix in ignore:
continue

words.append(prefix)

# Warn if we didn't find many examples
if len(words) < 5:
print("Warning: only found %d previous commits to guess from for" % 
len(words),
  fname, file=sys.stderr)

counts = Counter(words)
print(counts.most_common(1)[0][0])

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

Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_

[Michael Ellerman]

Geert Uytterhoeven <ge...@linux-m68k.org> writes:

> On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman <m...@ellerman.id.au> wrote:
>> Christoph Hellwig <h...@lst.de> writes:
>>
>>> We want to use the dma_direct_ namespace for a generic implementation,
>>> so rename powerpc to the second best choice: dma_nommu_.
>>
>> I'm not a fan of "nommu". Some of the users of direct ops *are* using an
>> IOMMU, they're just setting up a 1:1 mapping once at init time, rather
>> than mapping dynamically.
>>
>> Though I don't have a good idea for a better name, maybe "1to1",
>> "linear", "premapped" ?
>
> "identity"?

I think that would be wrong, but thanks for trying to help :)

The address on the device side is sometimes (often?) offset from the CPU
address. So eg. the device can DMA to RAM address 0x0 using address
0x800.

Identity would imply 0 == 0 etc.

I think "bijective" is the correct term, but that's probably a bit
esoteric.

cheers

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

Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_

[Michael Ellerman]

Christoph Hellwig  writes:

> We want to use the dma_direct_ namespace for a generic implementation,
> so rename powerpc to the second best choice: dma_nommu_.

I'm not a fan of "nommu". Some of the users of direct ops *are* using an
IOMMU, they're just setting up a 1:1 mapping once at init time, rather
than mapping dynamically.

Though I don't have a good idea for a better name, maybe "1to1",
"linear", "premapped" ?

cheers

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

Re: [PATCH 1/3] futex: remove duplicated code

[Michael Ellerman]

Jiri Slaby <jsl...@suse.cz> writes:

> There is code duplicated over all architecture's headers for
> futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
> and comparison of the result.
>
> Remove this duplication and leave up to the arches only the needed
> assembly which is now in arch_futex_atomic_op_inuser.

Looks OK and boots on powerpc. But I don't think anything's actually
calling those futex ops. Is there a test suite I should run?

Acked-by: Michael Ellerman <m...@ellerman.id.au> (powerpc)

cheers

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

Re: Build regressions/improvements in v4.9-rc1

[Michael Ellerman]

Alexey Brodkin <alexey.brod...@synopsys.com> writes:
> On Wed, 2016-10-19 at 22:50 +1100, Michael Ellerman wrote:
>> Vineet Gupta <vineet.gup...@synopsys.com> writes:
>> > On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
>> > > On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>> > > > On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>> > > > > > 48 error regressions:
>> > > > > > > 
>> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: 
>> > > > > > > bad instruction `llockd r2,[r0]':  => 476
>> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: 
>> > > > > > > bad instruction `llockd r2,[r13]':  =>
>> > > > > > > 475
>> > > > 
>> > > > [snip...]
>> > > > > > > 
>> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: 
>> > > > > > > bad instruction `scondd r4,[r8]':  => 516
>> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: 
>> > > > > > > bad instruction `scondd r6,[r3]':  => 478
>> > > > > arcv2/axs103_smp_defconfig
>> > 
>> > @Michael can I bother you to upgrade the tools or is this absolutely must 
>> > for you.
>> 
>> Happy to, just short on time.
>> 
>> I tried building a new toolchain with buildroot, using the instructions
>> from last time, but the resulting toolchain doesn't relocate, ie. it has
>> hard-coded paths in it. Any ideas?
>
> Hm... that's strange - it used to work but doesn't work with newer 
> Buildroot...
>
> Anyways if something very simple (i.e. with no extra libraries) works for you 
> just go
> ahead and grab pre-built image that Thomas Petazzoni builds.
>
> That's the most recent one:
> http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2

Thanks, I grabbed that and it works for axs103_smp_defconfig:

  http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/


It doesn't work for axs101_defconfig, saying:

  arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds.  
Stop.


So those are still failing:

  http://kisskb.ellerman.id.au/kisskb/buildresult/12841194/


cheers

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

Re: Build regressions/improvements in v4.9-rc1

[Michael Ellerman]

Vineet Gupta  writes:
> On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
>> On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>>> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
> 48 error regressions:
>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad 
>> instruction `llockd r2,[r0]':  => 476
>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad 
>> instruction `llockd r2,[r13]':  => 475
>>>
>>> [snip...]
>>>
>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad 
>> instruction `scondd r4,[r8]':  => 516
>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad 
>> instruction `scondd r6,[r3]':  => 478
 arcv2/axs103_smp_defconfig
>
> @Michael can I bother you to upgrade the tools or is this absolutely must for 
> you.

Happy to, just short on time.

I tried building a new toolchain with buildroot, using the instructions
from last time, but the resulting toolchain doesn't relocate, ie. it has
hard-coded paths in it. Any ideas?

cheers

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

Re: kisskb: FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Jun 09, 17:31

[Michael Ellerman]

On Thu, 2016-06-09 at 08:44 +, Alexey Brodkin wrote:
> Hi Michael,
> 
> On Thu, 2016-06-09 at 14:02 +0530, Vineet Gupta wrote:
> > Hi Michael,
> > 
> > On Thursday 09 June 2016 01:02 PM, nore...@ellerman.id.au wrote:
> > > 
> > > FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Jun 09, 17:31
> > > 
> > > http://kisskb.ellerman.id.au/kisskb/buildresult/12713783/
> > > 
> > > Commit:   Add linux-next specific files for 20160609
> > >   8f6027f7e808ed7c1fd8c8d37fc7a5076c683c4f
> > > Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4
> > > 
> > > Possible errors
> > > ---
> > > 
> > > {standard input}:18606: Error: Instruction with long immediate data in 
> > > delay slot
> > > make[2]: *** [block/cfq-iosched.o] Error 1
> > > make[1]: *** [block] Error 2
> > > make: *** [sub-make] Error 2
> > This problem has been fixed in tools since - can you switch to a newer 
> > toolchain -
> > such as one released last month. @Alexey can you point Michael to right 
> > buildroot
> > version ?
> 
> Unfortunately our most recent tools were released a little bit too late to 
> get in
> the most recent Buildroot version and so you'll need to build your toolchain
> from Buildroot's master branch. Basically everything after the following 
> commit will
> should work: 
> https://git.busybox.net/buildroot/commit/?id=caf515e25e699eb306d0b24986734790de80af28

OK thanks.

I'll try and get it build next week. Ping me if I forget.

cheers


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

Re: kisskb: FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Dec 10, 17:33

[Michael Ellerman]

On Thu, 2015-12-10 at 07:05 +, Vineet Gupta wrote:

> On Thursday 10 December 2015 12:05 PM, nore...@ellerman.id.au wrote:

> > FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Dec 10, 17:33
> > 
> > http://kisskb.ellerman.id.au/kisskb/buildresult/12564629/
> > 
> > Commit:   Add linux-next specific files for 20151210
> >   8225f4e85cb03daea14661380745886ce01fd83a
> > Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4
> > 
> > Possible errors
> > ---
> > 
> > include/linux/jiffies.h:10:33: fatal error: generated/timeconst.h: No such 
> > file or directory
> > make[2]: *** [kernel/bounds.s] Error 1
> > make[1]: *** [prepare0] Error 2
> > make: *** [sub-make] Error 2
> > 
> > No warnings found in log.
> 
> Hi Michael,
> 
> It is weird that no other arch build show similar errors.
> Building same linux-next on my machine seems to be fine as well.

That is weird. I'll ask it to rebuild it and see if it happens again.

Do you build with -j?

> From looking at logs it looks like some sort of a make / paralle jobs timing 
> issue
> at build farm.
> 
> P.S. Could you also update system to also cc lkml and
> linux-snps-arc@lists.infradead.org for such errors.

I'll add the arc list, I don't like to cc lkml so as not to annoy people with
too many error mails.

cheers


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