Re: [PATCH] sched: replace if (cond) BUG() with BUG_ON()
Le 17/03/2021 à 07:45, Jiapeng Chong a écrit : Fix the following coccicheck warnings: ./arch/powerpc/platforms/cell/spufs/sched.c:908:2-5: WARNING: Use BUG_ON instead of if condition followed by BUG. Consider using WARN_ON() instead of BUG_ON() if relevant. If not, explain in the commit message why we need to keep a BUG_ON(). See https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-and-bug-on Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- arch/powerpc/platforms/cell/spufs/sched.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/cell/spufs/sched.c b/arch/powerpc/platforms/cell/spufs/sched.c index 3692064..139a6ec 100644 --- a/arch/powerpc/platforms/cell/spufs/sched.c +++ b/arch/powerpc/platforms/cell/spufs/sched.c @@ -904,8 +904,7 @@ static noinline void spusched_tick(struct spu_context *ctx) struct spu_context *new = NULL; struct spu *spu = NULL; - if (spu_acquire(ctx)) - BUG(); /* a kernel thread never has signals pending */ + BUG_ON(spu_acquire(ctx)); /* a kernel thread never has signals pending */ if (ctx->state != SPU_STATE_RUNNABLE) goto out;
[PATCH v2] sched: replace if (cond) BUG() with WARN_ON()
Fix the following coccicheck warnings: ./arch/powerpc/platforms/cell/spufs/sched.c:908:2-5: WARNING: Use BUG_ON instead of if condition followed by BUG. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- Changes in v2: - replace BUG with WARN_ON. arch/powerpc/platforms/cell/spufs/sched.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/cell/spufs/sched.c b/arch/powerpc/platforms/cell/spufs/sched.c index 3692064..1031448 100644 --- a/arch/powerpc/platforms/cell/spufs/sched.c +++ b/arch/powerpc/platforms/cell/spufs/sched.c @@ -904,8 +904,7 @@ static noinline void spusched_tick(struct spu_context *ctx) struct spu_context *new = NULL; struct spu *spu = NULL; - if (spu_acquire(ctx)) - BUG(); /* a kernel thread never has signals pending */ + WARN_ON(spu_acquire(ctx)); /* a kernel thread never has signals pending */ if (ctx->state != SPU_STATE_RUNNABLE) goto out; -- 1.8.3.1
[PATCH v13 07/14] powerpc: inline huge vmap supported functions
This allows unsupported levels to be constant folded away, and so
p4d_free_pud_page can be removed because it's no longer linked to.
Cc: linuxppc-dev@lists.ozlabs.org
Acked-by: Michael Ellerman
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/vmalloc.h | 19 ---
arch/powerpc/mm/book3s64/radix_pgtable.c | 21 -
2 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/include/asm/vmalloc.h
b/arch/powerpc/include/asm/vmalloc.h
index 105abb73f075..3f0c153befb0 100644
--- a/arch/powerpc/include/asm/vmalloc.h
+++ b/arch/powerpc/include/asm/vmalloc.h
@@ -1,12 +1,25 @@
#ifndef _ASM_POWERPC_VMALLOC_H
#define _ASM_POWERPC_VMALLOC_H
+#include
#include
#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
-bool arch_vmap_p4d_supported(pgprot_t prot);
-bool arch_vmap_pud_supported(pgprot_t prot);
-bool arch_vmap_pmd_supported(pgprot_t prot);
+static inline bool arch_vmap_p4d_supported(pgprot_t prot)
+{
+ return false;
+}
+
+static inline bool arch_vmap_pud_supported(pgprot_t prot)
+{
+ /* HPT does not cope with large pages in the vmalloc area */
+ return radix_enabled();
+}
+
+static inline bool arch_vmap_pmd_supported(pgprot_t prot)
+{
+ return radix_enabled();
+}
#endif
#endif /* _ASM_POWERPC_VMALLOC_H */
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c
b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 743807fc210f..8da62afccee5 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -1082,22 +1082,6 @@ void radix__ptep_modify_prot_commit(struct
vm_area_struct *vma,
set_pte_at(mm, addr, ptep, pte);
}
-bool arch_vmap_pud_supported(pgprot_t prot)
-{
- /* HPT does not cope with large pages in the vmalloc area */
- return radix_enabled();
-}
-
-bool arch_vmap_pmd_supported(pgprot_t prot)
-{
- return radix_enabled();
-}
-
-int p4d_free_pud_page(p4d_t *p4d, unsigned long addr)
-{
- return 0;
-}
-
int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot)
{
pte_t *ptep = (pte_t *)pud;
@@ -1181,8 +1165,3 @@ int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
return 1;
}
-
-bool arch_vmap_p4d_supported(pgprot_t prot)
-{
- return false;
-}
--
2.23.0
[PATCH v13 06/14] mm: HUGE_VMAP arch support cleanup
This changes the awkward approach where architectures provide init
functions to determine which levels they can provide large mappings for,
to one where the arch is queried for each call.
This removes code and indirection, and allows constant-folding of dead
code for unsupported levels.
This also adds a prot argument to the arch query. This is unused
currently but could help with some architectures (e.g., some powerpc
processors can't map uncacheable memory with large pages).
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: "H. Peter Anvin"
Reviewed-by: Ding Tianhong
Acked-by: Catalin Marinas [arm64]
Signed-off-by: Nicholas Piggin
---
arch/arm64/include/asm/vmalloc.h | 8 ++
arch/arm64/mm/mmu.c | 10 +--
arch/powerpc/include/asm/vmalloc.h | 8 ++
arch/powerpc/mm/book3s64/radix_pgtable.c | 8 +-
arch/x86/include/asm/vmalloc.h | 7 ++
arch/x86/mm/ioremap.c| 12 +--
include/linux/io.h | 9 ---
include/linux/vmalloc.h | 6 ++
init/main.c | 1 -
mm/debug_vm_pgtable.c| 4 +-
mm/ioremap.c | 94 ++--
11 files changed, 87 insertions(+), 80 deletions(-)
diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h
index 2ca708ab9b20..597b40405319 100644
--- a/arch/arm64/include/asm/vmalloc.h
+++ b/arch/arm64/include/asm/vmalloc.h
@@ -1,4 +1,12 @@
#ifndef _ASM_ARM64_VMALLOC_H
#define _ASM_ARM64_VMALLOC_H
+#include
+
+#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
+bool arch_vmap_p4d_supported(pgprot_t prot);
+bool arch_vmap_pud_supported(pgprot_t prot);
+bool arch_vmap_pmd_supported(pgprot_t prot);
+#endif
+
#endif /* _ASM_ARM64_VMALLOC_H */
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 7484ea4f6ba0..639b9de61b1d 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1316,12 +1316,12 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys, int
*size, pgprot_t prot)
return dt_virt;
}
-int __init arch_ioremap_p4d_supported(void)
+bool arch_vmap_p4d_supported(pgprot_t prot)
{
- return 0;
+ return false;
}
-int __init arch_ioremap_pud_supported(void)
+bool arch_vmap_pud_supported(pgprot_t prot)
{
/*
* Only 4k granule supports level 1 block mappings.
@@ -1331,9 +1331,9 @@ int __init arch_ioremap_pud_supported(void)
!IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
}
-int __init arch_ioremap_pmd_supported(void)
+bool arch_vmap_pmd_supported(pgprot_t prot)
{
- /* See arch_ioremap_pud_supported() */
+ /* See arch_vmap_pud_supported() */
return !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
}
diff --git a/arch/powerpc/include/asm/vmalloc.h
b/arch/powerpc/include/asm/vmalloc.h
index b992dfaaa161..105abb73f075 100644
--- a/arch/powerpc/include/asm/vmalloc.h
+++ b/arch/powerpc/include/asm/vmalloc.h
@@ -1,4 +1,12 @@
#ifndef _ASM_POWERPC_VMALLOC_H
#define _ASM_POWERPC_VMALLOC_H
+#include
+
+#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
+bool arch_vmap_p4d_supported(pgprot_t prot);
+bool arch_vmap_pud_supported(pgprot_t prot);
+bool arch_vmap_pmd_supported(pgprot_t prot);
+#endif
+
#endif /* _ASM_POWERPC_VMALLOC_H */
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c
b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 98f0b243c1ab..743807fc210f 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -1082,13 +1082,13 @@ void radix__ptep_modify_prot_commit(struct
vm_area_struct *vma,
set_pte_at(mm, addr, ptep, pte);
}
-int __init arch_ioremap_pud_supported(void)
+bool arch_vmap_pud_supported(pgprot_t prot)
{
/* HPT does not cope with large pages in the vmalloc area */
return radix_enabled();
}
-int __init arch_ioremap_pmd_supported(void)
+bool arch_vmap_pmd_supported(pgprot_t prot)
{
return radix_enabled();
}
@@ -1182,7 +1182,7 @@ int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
return 1;
}
-int __init arch_ioremap_p4d_supported(void)
+bool arch_vmap_p4d_supported(pgprot_t prot)
{
- return 0;
+ return false;
}
diff --git a/arch/x86/include/asm/vmalloc.h b/arch/x86/include/asm/vmalloc.h
index 29837740b520..094ea2b565f3 100644
--- a/arch/x86/include/asm/vmalloc.h
+++ b/arch/x86/include/asm/vmalloc.h
@@ -1,6 +1,13 @@
#ifndef _ASM_X86_VMALLOC_H
#define _ASM_X86_VMALLOC_H
+#include
#include
+#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
+bool arch_vmap_p4d_supported(pgprot_t prot);
+bool arch_vmap_pud_supported(pgprot_t prot);
+bool arch_vmap_pmd_supported(pgprot_t prot);
+#endif
+
#endif /* _ASM_X86_VMALLOC_H */
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 9e5ccc56f8e0..fbaf0c447986 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@
[PATCH v13 14/14] powerpc/64s/radix: Enable huge vmalloc mappings
This reduces TLB misses by nearly 30x on a `git diff` workload on a
2-node POWER9 (59,800 -> 2,100) and reduces CPU cycles by 0.54%, due
to vfs hashes being allocated with 2MB pages.
Cc: linuxppc-dev@lists.ozlabs.org
Acked-by: Michael Ellerman
Signed-off-by: Nicholas Piggin
---
.../admin-guide/kernel-parameters.txt | 2 ++
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/module.c | 22 +++
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..1f481f904895 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3243,6 +3243,8 @@
nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
+ nohugevmalloc [PPC] Disable kernel huge vmalloc mappings.
+
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 386ae12d8523..b7cade9566da 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -181,6 +181,7 @@ config PPC
select GENERIC_GETTIMEOFDAY
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64 &&
PPC_RADIX_MMU
+ select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_KASAN if PPC32 && PPC_PAGE_SHIFT <= 14
select HAVE_ARCH_KASAN_VMALLOC if PPC32 && PPC_PAGE_SHIFT <= 14
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index a211b0253cdb..cdb2d88c54e7 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -87,13 +88,26 @@ int module_finalize(const Elf_Ehdr *hdr,
return 0;
}
-#ifdef MODULES_VADDR
void *module_alloc(unsigned long size)
{
+ unsigned long start = VMALLOC_START;
+ unsigned long end = VMALLOC_END;
+
+#ifdef MODULES_VADDR
BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
+ start = MODULES_VADDR;
+ end = MODULES_END;
+#endif
+
+ /*
+* Don't do huge page allocations for modules yet until more testing
+* is done. STRICT_MODULE_RWX may require extra work to support this
+* too.
+*/
- return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
GFP_KERNEL,
- PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
NUMA_NO_NODE,
+ return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL,
+ PAGE_KERNEL_EXEC,
+ VM_NO_HUGE_VMAP | VM_FLUSH_RESET_PERMS,
+ NUMA_NO_NODE,
__builtin_return_address(0));
}
-#endif
--
2.23.0
[PATCH] sched: replace if (cond) BUG() with BUG_ON()
Fix the following coccicheck warnings: ./arch/powerpc/platforms/cell/spufs/sched.c:908:2-5: WARNING: Use BUG_ON instead of if condition followed by BUG. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- arch/powerpc/platforms/cell/spufs/sched.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/cell/spufs/sched.c b/arch/powerpc/platforms/cell/spufs/sched.c index 3692064..139a6ec 100644 --- a/arch/powerpc/platforms/cell/spufs/sched.c +++ b/arch/powerpc/platforms/cell/spufs/sched.c @@ -904,8 +904,7 @@ static noinline void spusched_tick(struct spu_context *ctx) struct spu_context *new = NULL; struct spu *spu = NULL; - if (spu_acquire(ctx)) - BUG(); /* a kernel thread never has signals pending */ + BUG_ON(spu_acquire(ctx)); /* a kernel thread never has signals pending */ if (ctx->state != SPU_STATE_RUNNABLE) goto out; -- 1.8.3.1
Re: [PATCH] powerpc: arch/powerpc/kernel/setup_64.c - cleanup warnings
"heying (H)" writes:
> Thank you for your reply.
>
>
> 在 2021/3/17 11:04, Daniel Axtens 写道:
>> Hi He Ying,
>>
>> Thank you for this patch.
>>
>> I'm not sure what the precise rules for Fixes are, but I wonder if this
>> should have:
>>
>> Fixes: 9a32a7e78bd0 ("powerpc/64s: flush L1D after user accesses")
>> Fixes: f79643787e0a ("powerpc/64s: flush L1D on kernel entry")
>
> Is that necessary for warning cleanups? I thought 'Fixes' tags are
> needed only for
>
> bugfix patches. Can someone tell me whether I am right?
Yeah, I'm not sure either. Hopefully mpe will let us know.
Kind regards,
Daniel
>
>>
>> Those are the commits that added the entry_flush and uaccess_flush
>> symbols. Perhaps one for rfi_flush too but I'm not sure what commit
>> introduced that.
>>
>> Kind regards,
>> Daniel
>>
>>> warning: symbol 'rfi_flush' was not declared.
>>> warning: symbol 'entry_flush' was not declared.
>>> warning: symbol 'uaccess_flush' was not declared.
>>> We found warnings above in arch/powerpc/kernel/setup_64.c by using
>>> sparse tool.
>>>
>>> Define 'entry_flush' and 'uaccess_flush' as static because they are not
>>> referenced outside the file. Include asm/security_features.h in which
>>> 'rfi_flush' is declared.
>>>
>>> Reported-by: Hulk Robot
>>> Signed-off-by: He Ying
>>> ---
>>> arch/powerpc/kernel/setup_64.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
>>> index 560ed8b975e7..f92d72a7e7ce 100644
>>> --- a/arch/powerpc/kernel/setup_64.c
>>> +++ b/arch/powerpc/kernel/setup_64.c
>>> @@ -68,6 +68,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "setup.h"
>>>
>>> @@ -949,8 +950,8 @@ static bool no_rfi_flush;
>>> static bool no_entry_flush;
>>> static bool no_uaccess_flush;
>>> bool rfi_flush;
>>> -bool entry_flush;
>>> -bool uaccess_flush;
>>> +static bool entry_flush;
>>> +static bool uaccess_flush;
>>> DEFINE_STATIC_KEY_FALSE(uaccess_flush_key);
>>> EXPORT_SYMBOL(uaccess_flush_key);
>>>
>>> --
>>> 2.17.1
>> .
Re: [PATCH v9 3/8] powerpc/kprobes: Mark newly allocated probes as RO
Le 16/03/2021 à 04:17, Jordan Niethe a écrit : From: Russell Currey With CONFIG_STRICT_KERNEL_RWX=y and CONFIG_KPROBES=y, there will be one W+X page at boot by default. This can be tested with CONFIG_PPC_PTDUMP=y and CONFIG_PPC_DEBUG_WX=y set, and checking the kernel log during boot. Add an arch specific insn page allocator which returns RO pages if STRICT_KERNEL_RWX is enabled. This page is only written to with patch_instruction() which is able to write RO pages. Did you investigate BPF ? The problematic looks more or less similar to kprobe: bpf_jit_compile() in arch/powerpc/net/bpf_jit_comp.c calls module_alloc(), which provides it with PAGE_KERNEL_TEXT memory, ie RWX. That function is only used on PPC32 which still has Classic BPF, and this is about to go away with future series https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1608112796.git.christophe.le...@csgroup.eu/ PPC64 has Extended BPF instead, and PPC32 will it the future too. bpf_int_jit_compile() in arch/powerpc/net/bpf_jit_comp64.c calls bpf_jit_binary_alloc() which uses bpf_jit_alloc_exec(). bpf_jit_alloc_exec() is a weak function that should be redefined for powerpc I think, more or less like alloc_insn_page() for kprobes. Christophe
Re: [PATCH v2] sched: replace if (cond) BUG() with WARN_ON()
On Wed, Mar 17, 2021 at 8:35 AM Jiapeng Chong wrote: > > Fix the following coccicheck warnings: > > ./arch/powerpc/platforms/cell/spufs/sched.c:908:2-5: WARNING: Use BUG_ON > instead of if condition followed by BUG. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong If you change it from BUG() to WARN_ON(), you should explain why it's safe to do that in this case. Here it is not, since the following spu_release() will end up making things worse if the acquire failed. Also if there was a signal pending, then spusched_tick() will just get called again and constantly print these warnings. There is probably a way to use WARN_ON_ONCE() here, in combination with a way to terminate the thread safely, but this has to be done carefully. Arnd
Re: Advice needed on SMP regression after cpu_core_mask change
On 3/17/21 2:00 PM, Daniel Henrique Barboza wrote:
> Hello,
>
> Patch 4bce545903fa ("powerpc/topology: Update topology_core_cpumask")
> introduced
> a regression in both upstream and RHEL downstream kernels [1]. The assumption
> made
> in the commit:
>
> "Further analysis shows that cpu_core_mask and cpu_cpu_mask for any CPU would
> be
> equal on Power"
>
> Doesn't seem to be true. After this commit, QEMU is now unable to set single
> NUMA
> node SMP topologies such as:
>
> -smp 8,maxcpus=8,cores=2,threads=2,sockets=2
>
> lscpu will give the following output in this case:
>
> # lscpu
> Architecture: ppc64le
> Byte Order: Little Endian
> CPU(s): 8
> On-line CPU(s) list: 0-7
> Thread(s) per core: 2
> Core(s) per socket: 4
> Socket(s): 1
> NUMA node(s): 1
> Model: 2.2 (pvr 004e 1202)
> Model name: POWER9 (architected), altivec supported
> Hypervisor vendor: KVM
> Virtualization type: para
> L1d cache: 32K
> L1i cache: 32K
> NUMA node0 CPU(s): 0-7
>
>
> This is happening because the macro cpu_cpu_mask(cpu) expands to
> cpumask_of_node(cpu_to_node(cpu)), which in turn expands to
> node_to_cpumask_map[node].
> node_to_cpumask_map is a NUMA array that maps CPUs to NUMA nodes (Aneesh is
> on CC to
> correct me if I'm wrong). We're now associating sockets to NUMA nodes
> directly.
>
> If I add a second NUMA node then I can get the intended smp topology:
>
> -smp 8,maxcpus=8,cores=2,threads=2,sockets=2
> -numa node,memdev=mem0,cpus=0-3,nodeid=0 \
> -numa node,memdev=mem1,cpus=4-7,nodeid=1 \
>
> # lscpu
> Architecture: ppc64le
> Byte Order: Little Endian
> CPU(s): 8
> On-line CPU(s) list: 0-7
> Thread(s) per core: 2
> Core(s) per socket: 2
> Socket(s): 2
> NUMA node(s): 2
> Model: 2.2 (pvr 004e 1202)
> Model name: POWER9 (architected), altivec supported
> Hypervisor vendor: KVM
> Virtualization type: para
> L1d cache: 32K
> L1i cache: 32K
> NUMA node0 CPU(s): 0-3
> NUMA node1 CPU(s): 4-7
>
>
> However, if I try a single socket with multiple NUMA nodes topology, which is
> the case
> of Power10, e.g.:
>
>
> -smp 8,maxcpus=8,cores=4,threads=2,sockets=1
> -numa node,memdev=mem0,cpus=0-3,nodeid=0 \
> -numa node,memdev=mem1,cpus=4-7,nodeid=1 \
>
>
> This is the result:
>
> # lscpu
> Architecture: ppc64le
> Byte Order: Little Endian
> CPU(s): 8
> On-line CPU(s) list: 0-7
> Thread(s) per core: 2
> Core(s) per socket: 2
> Socket(s): 2
> NUMA node(s): 2
> Model: 2.2 (pvr 004e 1202)
> Model name: POWER9 (architected), altivec supported
> Hypervisor vendor: KVM
> Virtualization type: para
> L1d cache: 32K
> L1i cache: 32K
> NUMA node0 CPU(s): 0-3
> NUMA node1 CPU(s): 4-7
>
>
> This confirms my suspicions that, at this moment, we're making sockets ==
> NUMA nodes.
Yes. I don't think we can do better on PAPR and the above examples
seem to confirm that the "sockets" definition is simply ignored.
> Cedric, the reason I'm CCing you is because this is related to ibm,chip-id.
> The commit
> after the one that caused the regression, 4ca234a9cbd7c3a65 ("powerpc/smp:
> Stop updating
> cpu_core_mask"), is erasing the code that calculated cpu_core_mask.
> cpu_core_mask, despite
> its shortcomings that caused its removal, was giving a precise SMP topology.
> And it was
> using physical_package_id/'ibm,chip-id' for that.
ibm,chip-id is a no-no on pSeries. I guess this is inherent to PAPR which
is hiding a lot of the underlying HW and topology. May be we are trying
to reconcile two orthogonal views of machine virtualization ...
> Checking in QEMU I can say that the ibm,chip-id calculation is the only place
> in the code
> that cares about cores per socket information. The kernel is now ignoring
> that, starting
> on 4bce545903fa, and now QEMU is unable to provide this info to the guest.
>
> If we're not going to use ibm,chip-id any longer, which seems sensible given
> that PAPR does
> not declare it, we need another way of letting the guest know how much cores
> per socket
> we want.
The RTAS call "ibm,get-system-parameter" with token "Processor Module
Information" returns that kind of information :
2 byte binary number (N) of module types followed by N module specifiers of
the form:
2 byte binary number (M) of sockets of this module type
2 byte binary number (L) of chips per this module type
2 byte binary number (K) of cores per chip in this module type.
See the values in these sysfs files :
cat /sys/devices/hv_24x7/interface/{sockets,chipspersocket,coresperchip}
But I am afraid these are host level information and not guest/LPAR.
I didn't find any LPAR level properties or hcalls in the PAPR document.
They need to be specified.
or
We can add extra properties like ibm,chip-id but making sure
Advice needed on SMP regression after cpu_core_mask change
Hello,
Patch 4bce545903fa ("powerpc/topology: Update topology_core_cpumask") introduced
a regression in both upstream and RHEL downstream kernels [1]. The assumption
made
in the commit:
"Further analysis shows that cpu_core_mask and cpu_cpu_mask for any CPU would be
equal on Power"
Doesn't seem to be true. After this commit, QEMU is now unable to set single
NUMA
node SMP topologies such as:
-smp 8,maxcpus=8,cores=2,threads=2,sockets=2
lscpu will give the following output in this case:
# lscpu
Architecture:ppc64le
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s):1
Model: 2.2 (pvr 004e 1202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: KVM
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
NUMA node0 CPU(s): 0-7
This is happening because the macro cpu_cpu_mask(cpu) expands to
cpumask_of_node(cpu_to_node(cpu)), which in turn expands to
node_to_cpumask_map[node].
node_to_cpumask_map is a NUMA array that maps CPUs to NUMA nodes (Aneesh is on
CC to
correct me if I'm wrong). We're now associating sockets to NUMA nodes directly.
If I add a second NUMA node then I can get the intended smp topology:
-smp 8,maxcpus=8,cores=2,threads=2,sockets=2
-numa node,memdev=mem0,cpus=0-3,nodeid=0 \
-numa node,memdev=mem1,cpus=4-7,nodeid=1 \
# lscpu
Architecture:ppc64le
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 2
NUMA node(s):2
Model: 2.2 (pvr 004e 1202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: KVM
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
NUMA node0 CPU(s): 0-3
NUMA node1 CPU(s): 4-7
However, if I try a single socket with multiple NUMA nodes topology, which is
the case
of Power10, e.g.:
-smp 8,maxcpus=8,cores=4,threads=2,sockets=1
-numa node,memdev=mem0,cpus=0-3,nodeid=0 \
-numa node,memdev=mem1,cpus=4-7,nodeid=1 \
This is the result:
# lscpu
Architecture:ppc64le
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 2
NUMA node(s):2
Model: 2.2 (pvr 004e 1202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: KVM
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
NUMA node0 CPU(s): 0-3
NUMA node1 CPU(s): 4-7
This confirms my suspicions that, at this moment, we're making sockets == NUMA
nodes.
Cedric, the reason I'm CCing you is because this is related to ibm,chip-id. The
commit
after the one that caused the regression, 4ca234a9cbd7c3a65 ("powerpc/smp: Stop
updating
cpu_core_mask"), is erasing the code that calculated cpu_core_mask.
cpu_core_mask, despite
its shortcomings that caused its removal, was giving a precise SMP topology.
And it was
using physical_package_id/'ibm,chip-id' for that.
Checking in QEMU I can say that the ibm,chip-id calculation is the only place
in the code
that cares about cores per socket information. The kernel is now ignoring that,
starting
on 4bce545903fa, and now QEMU is unable to provide this info to the guest.
If we're not going to use ibm,chip-id any longer, which seems sensible given
that PAPR does
not declare it, we need another way of letting the guest know how much cores
per socket
we want.
[1] https://bugzilla.redhat.com/1934421
Thanks,
DHB
Re: [PATCH v3 34/41] KVM: PPC: Book3S HV: Remove support for dependent threads mode on P9
Nicholas Piggin writes:
> Radix guest support will be removed from the P7/8 path, so disallow
> dependent threads mode on P9.
>
> Signed-off-by: Nicholas Piggin
> ---
> arch/powerpc/include/asm/kvm_host.h | 1 -
> arch/powerpc/kvm/book3s_hv.c| 27 +--
> 2 files changed, 5 insertions(+), 23 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h
> b/arch/powerpc/include/asm/kvm_host.h
> index 05fb00d37609..dd017dfa4e65 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -304,7 +304,6 @@ struct kvm_arch {
> u8 fwnmi_enabled;
> u8 secure_guest;
> u8 svm_enabled;
> - bool threads_indep;
> bool nested_enable;
> bool dawr1_enabled;
> pgd_t *pgtable;
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index cb428e2f7140..928ed8180d9d 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -103,13 +103,9 @@ static int target_smt_mode;
> module_param(target_smt_mode, int, 0644);
> MODULE_PARM_DESC(target_smt_mode, "Target threads per core (0 = max)");
>
> -static bool indep_threads_mode = true;
> -module_param(indep_threads_mode, bool, S_IRUGO | S_IWUSR);
> -MODULE_PARM_DESC(indep_threads_mode, "Independent-threads mode (only on
> POWER9)");
> -
> static bool one_vm_per_core;
> module_param(one_vm_per_core, bool, S_IRUGO | S_IWUSR);
> -MODULE_PARM_DESC(one_vm_per_core, "Only run vCPUs from the same VM on a core
> (requires indep_threads_mode=N)");
> +MODULE_PARM_DESC(one_vm_per_core, "Only run vCPUs from the same VM on a core
> (requires POWER8 or older)");
Isn't this also a security feature, where there was an ask to make sure
threads/vCPU from other VM won't run on this core? In that context isn't
this applicable also for P9?
>
> #ifdef CONFIG_KVM_XICS
> static const struct kernel_param_ops module_param_ops = {
> @@ -2227,7 +2223,7 @@ static int kvmppc_set_one_reg_hv(struct kvm_vcpu *vcpu,
> u64 id,
> */
> static int threads_per_vcore(struct kvm *kvm)
> {
> - if (kvm->arch.threads_indep)
> + if (cpu_has_feature(CPU_FTR_ARCH_300))
> return 1;
> return threads_per_subcore;
> }
> @@ -4319,7 +4315,7 @@ static int kvmppc_vcpu_run_hv(struct kvm_vcpu *vcpu)
> vcpu->arch.state = KVMPPC_VCPU_BUSY_IN_HOST;
>
> do {
> - if (kvm->arch.threads_indep && kvm_is_radix(kvm))
> + if (kvm_is_radix(kvm))
> r = kvmhv_run_single_vcpu(vcpu, ~(u64)0,
> vcpu->arch.vcore->lpcr);
> else
> @@ -4934,21 +4930,8 @@ static int kvmppc_core_init_vm_hv(struct kvm *kvm)
> /*
>* Track that we now have a HV mode VM active. This blocks secondary
>* CPU threads from coming online.
> - * On POWER9, we only need to do this if the "indep_threads_mode"
> - * module parameter has been set to N.
>*/
> - if (cpu_has_feature(CPU_FTR_ARCH_300)) {
> - if (!indep_threads_mode && !cpu_has_feature(CPU_FTR_HVMODE)) {
> - pr_warn("KVM: Ignoring indep_threads_mode=N in nested
> hypervisor\n");
> - kvm->arch.threads_indep = true;
> - } else if (!indep_threads_mode &&
> cpu_has_feature(CPU_FTR_P9_RADIX_PREFETCH_BUG)) {
> - pr_warn("KVM: Ignoring indep_threads_mode=N on
> pre-DD2.2 POWER9\n");
> - kvm->arch.threads_indep = true;
> - } else {
> - kvm->arch.threads_indep = indep_threads_mode;
> - }
> - }
> - if (!kvm->arch.threads_indep)
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> kvm_hv_vm_activated();
>
> /*
> @@ -4989,7 +4972,7 @@ static void kvmppc_core_destroy_vm_hv(struct kvm *kvm)
> {
> debugfs_remove_recursive(kvm->arch.debugfs_dir);
>
> - if (!kvm->arch.threads_indep)
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> kvm_hv_vm_deactivated();
>
> kvmppc_free_vcores(kvm);
> --
> 2.23.0
Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
On Wed, Mar 17, 2021 at 4:51 AM Kefeng Wang wrote: > > 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 applied patch (5.12.0-rc3-00020-g1df27313f50a-dirty) over linus.git and tested boot on a sparc64 virtual machine (ldom) - boots.
Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
..snip..
> int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int
> verbose)
> {
..snip..
> /*
>* Allocate and initialize the free list array. This array is used
>* to find contiguous free memory regions of size up to IO_TLB_SEGSIZE
> - * between io_tlb_start and io_tlb_end.
> + * between mem->start and mem->end.
>*/
> - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(int));
> - io_tlb_list = memblock_alloc(alloc_size, PAGE_SIZE);
> - if (!io_tlb_list)
> + alloc_size = PAGE_ALIGN(mem->nslabs * sizeof(int));
> + mem->list = memblock_alloc(alloc_size, PAGE_SIZE);
> + if (!mem->list)
> panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> __func__, alloc_size, PAGE_SIZE);
>
> - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(phys_addr_t));
> - io_tlb_orig_addr = memblock_alloc(alloc_size, PAGE_SIZE);
> - if (!io_tlb_orig_addr)
> + alloc_size = PAGE_ALIGN(mem->nslabs * sizeof(phys_addr_t));
> + mem->orig_addr = memblock_alloc(alloc_size, PAGE_SIZE);
> + if (!mem->orig_addr)
> panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> __func__, alloc_size, PAGE_SIZE);
>
> - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> - if (!io_tlb_alloc_size)
> - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> - __func__, alloc_size, PAGE_SIZE);
Shouldn't this be converted to:
mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
if (...)
Seems that it got lost in the search and replace?
> -
> - for (i = 0; i < io_tlb_nslabs; i++) {
> - io_tlb_list[i] = IO_TLB_SEGSIZE - io_tlb_offset(i);
> - io_tlb_orig_addr[i] = INVALID_PHYS_ADDR;
> - io_tlb_alloc_size[i] = 0;
> + for (i = 0; i < mem->nslabs; i++) {
> + mem->list[i] = IO_TLB_SEGSIZE - io_tlb_offset(i);
> + mem->orig_addr[i] = INVALID_PHYS_ADDR;
> + mem->alloc_size[i] = 0;
> }
> - io_tlb_index = 0;
> no_iotlb_memory = false;
>
> if (verbose)
> swiotlb_print_info();
>
> - swiotlb_set_max_segment(io_tlb_nslabs << IO_TLB_SHIFT);
> + swiotlb_set_max_segment(mem->nslabs << IO_TLB_SHIFT);
> return 0;
> }
>
..snip..
Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
On Wed, Mar 17, 2021 at 01:42:07PM +, Konrad Rzeszutek Wilk wrote:
> > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > - if (!io_tlb_alloc_size)
> > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > - __func__, alloc_size, PAGE_SIZE);
>
> Shouldn't this be converted to:
> mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> if (...)
>
> Seems that it got lost in the search and replace?
Yes, I messed that up during the rebase. That being said it magically
gets fixed in the next patch..
Re: [PATCH v2 04/11] powerpc/64e/interrupt: use new interrupt return
Excerpts from Christophe Leroy's message of March 16, 2021 8:49 pm: > > > Le 16/03/2021 à 11:41, Nicholas Piggin a écrit : >> Update the new C and asm interrupt return code to account for 64e >> specifics, switch over to use it. >> >> The now-unused old ret_from_except code, that was moved to 64e after the >> 64s conversion, is removed. >> >> Signed-off-by: Nicholas Piggin >> --- >> arch/powerpc/include/asm/asm-prototypes.h | 2 - >> arch/powerpc/include/asm/ppc_asm.h| 20 -- >> arch/powerpc/kernel/asm-offsets.c | 10 - >> arch/powerpc/kernel/exceptions-64e.S | 321 ++ >> arch/powerpc/kernel/irq.c | 76 - >> 5 files changed, 25 insertions(+), 404 deletions(-) >> > >> diff --git a/arch/powerpc/kernel/asm-offsets.c >> b/arch/powerpc/kernel/asm-offsets.c >> index 85ba2b0bc8d8..c880ad18b851 100644 >> --- a/arch/powerpc/kernel/asm-offsets.c >> +++ b/arch/powerpc/kernel/asm-offsets.c >> @@ -282,21 +282,11 @@ int main(void) >> OFFSET(PACAHWCPUID, paca_struct, hw_cpu_id); >> OFFSET(PACAKEXECSTATE, paca_struct, kexec_state); >> OFFSET(PACA_DSCR_DEFAULT, paca_struct, dscr_default); >> -OFFSET(ACCOUNT_STARTTIME, paca_struct, accounting.starttime); >> -OFFSET(ACCOUNT_STARTTIME_USER, paca_struct, accounting.starttime_user); >> -OFFSET(ACCOUNT_USER_TIME, paca_struct, accounting.utime); >> -OFFSET(ACCOUNT_SYSTEM_TIME, paca_struct, accounting.stime); >> #ifdef CONFIG_PPC_BOOK3E >> OFFSET(PACA_TRAP_SAVE, paca_struct, trap_save); >> #endif >> OFFSET(PACA_SPRG_VDSO, paca_struct, sprg_vdso); >> #else /* CONFIG_PPC64 */ > > The #else is useless Thanks. I'll hold off re posting until there is some more activity. Thanks, Nick
[PATCH] powerpc: kernel: Trivial typo fix in the file kgdb.c
s/procesing/processing/ Signed-off-by: Bhaskar Chowdhury --- arch/powerpc/kernel/kgdb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c index 409080208a6c..7dd2ad3603ad 100644 --- a/arch/powerpc/kernel/kgdb.c +++ b/arch/powerpc/kernel/kgdb.c @@ -376,7 +376,7 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long pc) } /* - * This function does PowerPC specific procesing for interfacing to gdb. + * This function does PowerPC specific processing for interfacing to gdb. */ int kgdb_arch_handle_exception(int vector, int signo, int err_code, char *remcom_in_buffer, char *remcom_out_buffer, -- 2.30.2
[PATCH 00/36] [Set 4] Rid W=1 warnings in SCSI
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Lee Jones (36): scsi: myrb: Demote non-conformant kernel-doc headers and fix others scsi: ipr: Fix incorrect function names in their headers scsi: mvumi: Fix formatting and doc-rot issues scsi: sd_zbc: Place function name into header scsi: pmcraid: Fix a whole host of kernel-doc issues scsi: sd: Fix function name in header scsi: aic94xx: aic94xx_dump: Correct misspelling of function asd_dump_seq_state() scsi: be2iscsi: be_main: Ensure function follows directly after its header scsi: dc395x: Fix some function param descriptions scsi: initio: Fix a few kernel-doc misdemeanours scsi: a100u2w: Fix some misnaming and formatting issues scsi: myrs: Add missing ':' to make the kernel-doc checker happy scsi: pmcraid: Correct function name pmcraid_show_adapter_id() in header scsi: mpt3sas: mpt3sas_scs: Fix a few kernel-doc issues scsi: be2iscsi: be_main: Demote incomplete/non-conformant kernel-doc header scsi: isci: phy: Fix a few different kernel-doc related issues scsi: fnic: fnic_scsi: Demote non-conformant kernel-doc headers scsi: fnic: fnic_fcs: Kernel-doc headers must contain the function name scsi: isci: phy: Provide function name and demote non-conforming header scsi: isci: request: Fix a myriad of kernel-doc issues scsi: isci: host: Fix bunch of kernel-doc related issues scsi: isci: task: Demote non-conformant header and remove superfluous param scsi: isci: remote_node_table: Fix a bunch of kernel-doc misdemeanours scsi: isci: remote_node_context: Fix one function header and demote a couple more scsi: isci: port_config: Fix a bunch of doc-rot and demote abuses scsi: isci: remote_device: Fix a bunch of doc-rot issues scsi: isci: request: Fix doc-rot issue relating to 'ireq' param scsi: isci: port: Fix a bunch of kernel-doc issues scsi: isci: remote_node_context: Demote kernel-doc abuse scsi: isci: remote_node_table: Provide some missing params and remove others scsi: cxlflash: main: Fix a little do-rot scsi: cxlflash: superpipe: Fix a few misnaming issues scsi: ibmvscsi: Fix a bunch of kernel-doc related issues scsi: ibmvscsi: ibmvfc: Fix a bunch of misdocumentation scsi: ibmvscsi_tgt: ibmvscsi_tgt: Remove duplicate section 'NOTE' scsi: cxlflash: vlun: Fix some misnaming related doc-rot drivers/scsi/a100u2w.c | 8 +-- drivers/scsi/aic94xx/aic94xx_dump.c | 2 +- drivers/scsi/be2iscsi/be_main.c | 5 +- drivers/scsi/cxlflash/main.c | 8 +-- drivers/scsi/cxlflash/superpipe.c| 6 +- drivers/scsi/cxlflash/vlun.c | 8 +-- drivers/scsi/dc395x.c| 3 +- drivers/scsi/fnic/fnic_fcs.c | 2 +- drivers/scsi/fnic/fnic_scsi.c| 6 +- drivers/scsi/ibmvscsi/ibmvfc.c | 29 ++ drivers/scsi/ibmvscsi/ibmvscsi.c | 70 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 8 +-- drivers/scsi/initio.c| 13 ++--- drivers/scsi/ipr.c | 8 +-- drivers/scsi/isci/host.c | 37 ++--- drivers/scsi/isci/phy.c | 34 ++-- drivers/scsi/isci/port.c | 58 ++-- drivers/scsi/isci/port_config.c | 37 +++-- drivers/scsi/isci/remote_device.c| 31 ++- drivers/scsi/isci/remote_node_context.c | 13 + drivers/scsi/isci/remote_node_table.c| 64 +++--- drivers/scsi/isci/request.c | 60 ++-- drivers/scsi/isci/task.c | 3 +- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 18 +++--- drivers/scsi/mvumi.c | 5 +- drivers/scsi/myrb.c | 47 drivers/scsi/myrs.c | 6 +- drivers/scsi/pmcraid.c | 70 drivers/scsi/sd.c| 2 +- drivers/scsi/sd_zbc.c| 2 +- 30 files changed, 329 insertions(+), 334 deletions(-) Cc: Alan Cox Cc: Alex Davis Cc: Ali Akcaagac Cc: Anil Ravindranath Cc: Artur Paszkiewicz Cc: Badari Pulavarty Cc: Bas Vermeulen Cc: Benjamin Herrenschmidt Cc: Brian King Cc: Brian King Cc: Brian Macy Cc: "Bryant G. Ly" Cc: Christoph Hellwig Cc: "C.L. Huang" Cc: Colin DeVilbiss Cc: Dave Boutcher Cc: Dave Boutcher Cc: David Chaw Cc: dc3...@twibble.org Cc: Douglas Gilbert Cc: Doug Ledford Cc: Drew Eckhardt Cc: Erich Chen Cc: Eric Youngdale Cc: FUJITA Tomonori Cc: Hannes Reinecke Cc: Hannes Reinecke Cc: "James E.J. Bottomley" Cc: Jamie Lenehan Cc: Jirka Hanika Cc: Jitendra Bhivare Cc: Karan Tilak Kumar Cc: Ketan Mukadam Cc: Kurt Garloff Cc: Lee Jones Cc: Le Moal Cc: "Leonard N. Zubkoff" Cc: Linda Xie Cc: linux-driv...@broadcom.com Cc:
Re: [PATCH 4/4] tools/perf: Support pipeline stage cycles for powerpc
On Wed, Mar 17, 2021 at 05:01:27PM +0530, Athira Rajeev wrote:
> class="ApplePlainTextBody"> class="ApplePlainTextBody">On 16-Mar-2021, at
> 4:48 AM, Jiri Olsa jo...@redhat.com wrote:On Mon, Mar 15,
> 2021 at 01:22:09PM +0530, Athira Rajeev wrote:SNIP type="cite">++static char *setup_dynamic_sort_keys(char
> *str)+{+
> unsigned int j;++ style="white-space:pre"> if (sort__mode ==
> SORT_MODE__MEMORY)+
> for
> (j = 0; j ARRAY_SIZE(dynamic_sort_keys_mem); j++)+ class="Apple-tab-span" style="white-space:pre"> class="Apple-tab-span" style="white-space:pre"> class="Apple-tab-span" style="white-space:pre">if
> (arch_support_dynamic_key(dynamic_sort_keys_mem[j])) {+ class="Apple-tab-span" style="white-space:pre"> class="Apple-tab-span" style="white-space:pre"> class="Apple-tab-span" style="white-space:pre"> class="Apple-tab-span" style="white-space:pre">str =
> suffix_if_not_in(dynamic_sort_keys_mem[j], str);+ class="Apple-tab-span" style="white-space:pre"> class="Apple-tab-span" style="white-space:pre"> class="Apple-tab-span" style="white-space:pre"> class="Apple-tab-span" style="white-space:pre">if (str ==
> NULL)+
> class="Apple-tab-span" style="white-space:pre"> class="Apple-tab-span" style="white-space:pre"> class="Apple-tab-span" style="white-space:pre">return
> str;+
> class="Apple-tab-span" style="white-space:pre">}++ class="Apple-tab-span" style="white-space:pre"> return
> str;+}+static int __setup_sorting(struct evlist
> *evlist){
> char *str;@@ -3050,6 +3085,12 @@ static int __setup_sorting(struct
> evlist *evlist)
>
> }
> }+
> str = setup_dynamic_sort_keys(str);+ style="white-space:pre">if (str == NULL) {+ class="Apple-tab-span" style="white-space:pre"> class="Apple-tab-span" style="white-space:pre">pr_err("Not enough
> memory to setup dynamic sort keys");+ style="white-space:pre"> style="white-space:pre">return -ENOMEM;+ class="Apple-tab-span" style="white-space:pre">
> }hum, so this is basicaly overloading the
> default_mem_sort_order forarchitecture, right?then I think it'd
> be easier just overload default_mem_sort_order directlyI was thinking
> more about adding extra (arch specific) loop tosort_dimension__add or
> somehow add arch's specific stuff
> tomemory_sort_dimensionsHi Jiri,Above patch
> was to append additional sort keys to sort order based onsort mode and
> architecture support. I had initially thought of defining twoorders ( say
> default_mem_sort_order plus mem_sort_order_pstage ). But ifnew sort keys
> gets added for mem mode in future, we will need to keepupdating both
> orders. So preferred the approach of "appending" supported sortkeys to
> default order.Following your thought on using "sort_dimension__add",
> I tried below approachwhich is easier. The new sort dimension
> "p_stage_cyc" is presently only supportedon powerpc. For unsupported
> platforms, we don't want to display itin the perf report output columns.
> Hence added check in sort_dimension__add()and skip the sort key incase
> its not applicable for particular arch.Please help to check if below
> approach looks fine.diff --git
> a/tools/perf/arch/powerpc/util/event.c
> b/tools/perf/arch/powerpc/util/event.cindex b80fbee83b6e..7205767d75eb
> 100644--- a/tools/perf/arch/powerpc/util/event.c+++
> b/tools/perf/arch/powerpc/util/event.c@@ -44,3 +44,10 @@ const char
> *arch_perf_header_entry__add(const char *se_header) class="Apple-tab-span" style="white-space:pre"> class="Apple-tab-span" style="white-space:pre">return "Dispatch
> Cyc"; return
> se_header; }++int arch_support_sort_key(const char
> *sort_key)+{+
> if (!strcmp(sort_key, "p_stage_cyc"))+ style="white-space:pre"> style="white-space:pre">return 1;+ style="white-space:pre"> return 0;+}diff --git
> a/tools/perf/util/event.h b/tools/perf/util/event.hindex
> 65f89e80916f..612a92aaaefb 100644--- a/tools/perf/util/event.h+++
> b/tools/perf/util/event.h@@ -429,5 +429,6 @@ char *get_page_size_name(u64
> size, char *str); void arch_perf_parse_sample_weight(struct perf_sample
> *data, const __u64 *array, u64 type); void
> arch_perf_synthesize_sample_weight(const struct perf_sample *data, __u64
> *array, u64 type); const char *arch_perf_header_entry__add(const char
> *se_header);+int arch_support_sort_key(const char *sort_key);
> #endif /* __PERF_RECORD_H */diff --git a/tools/perf/util/sort.c
> b/tools/perf/util/sort.cindex cbb3899e7eca..d8b0b0b43a81 100644---
> a/tools/perf/util/sort.c+++ b/tools/perf/util/sort.c@@ -47,6 +47,7 @@
> regex_t class="Apple-tab-span" style="white-space:pre">
> ignore_callees_regex; int style="white-space:pre">style="white-space:pre">have_ignore_callees = 0; enum
> sort_mode
> sort__mode = SORT_MODE__NORMAL; const char class="Apple-tab-span" style="white-space:pre">
> *dynamic_headers[] =
Re: [PATCH v2] rpadlpar: fix potential drc_name corruption in store functions
On Mon, 15 Mar 2021 15:48:21 -0600, Tyrel Datwyler wrote: > Both add_slot_store() and remove_slot_store() try to fix up the drc_name > copied from the store buffer by placing a NULL terminator at nbyte + 1 > or in place of a '\n' if present. However, the static buffer that we > copy the drc_name data into is not zeored and can contain anything past > the n-th byte. This is problematic if a '\n' byte appears in that buffer > after nbytes and the string copied into the store buffer was not NULL > terminated to start with as the strchr() search for a '\n' byte will mark > this incorrectly as the end of the drc_name string resulting in a drc_name > string that contains garbage data after the n-th byte. The following > debugging shows an example of the drmgr utility writing "PHB 4543" to > the add_slot sysfs attribute, but add_slot_store logging a corrupted > string value. > > [...] Applied to powerpc/fixes. [1/1] rpadlpar: fix potential drc_name corruption in store functions https://git.kernel.org/powerpc/c/cc7a0bb058b85ea03db87169c60c7cfdd5d34678 cheers
[PATCH -next] powerpc: kernel/time.c - cleanup warnings
We found these warnings in arch/powerpc/kernel/time.c as follows:
warning: symbol 'decrementer_max' was not declared. Should it be static?
warning: symbol 'rtc_lock' was not declared. Should it be static?
warning: symbol 'dtl_consumer' was not declared. Should it be static?
Declare 'decrementer_max' in arch/powerpc/include/asm/time.h. And include
proper header in which 'rtc_lock' is declared. Move 'dtl_consumer'
definition behind "include " because 'dtl_consumer' is declared
there.
Reported-by: Hulk Robot
Signed-off-by: He Ying
---
arch/powerpc/include/asm/time.h | 1 +
arch/powerpc/kernel/time.c | 7 +++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 8dd3cdb25338..2cd2b50bedda 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -22,6 +22,7 @@ extern unsigned long tb_ticks_per_jiffy;
extern unsigned long tb_ticks_per_usec;
extern unsigned long tb_ticks_per_sec;
extern struct clock_event_device decrementer_clockevent;
+extern u64 decrementer_max;
extern void generic_calibrate_decr(void);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index b67d93a609a2..409967713ca6 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
#include
@@ -150,10 +151,6 @@ bool tb_invalid;
u64 __cputime_usec_factor;
EXPORT_SYMBOL(__cputime_usec_factor);
-#ifdef CONFIG_PPC_SPLPAR
-void (*dtl_consumer)(struct dtl_entry *, u64);
-#endif
-
static void calc_cputime_factors(void)
{
struct div_result res;
@@ -179,6 +176,8 @@ static inline unsigned long read_spurr(unsigned long tb)
#include
+void (*dtl_consumer)(struct dtl_entry *, u64);
+
/*
* Scan the dispatch trace log and count up the stolen time.
* Should be called with interrupts disabled.
--
2.17.1
Re: [PATCH v9 2/8] powerpc/lib/code-patching: Set up Strict RWX patching earlier
Jordan Niethe writes: > On Tue, Mar 16, 2021 at 5:32 PM Christophe Leroy > wrote: >> >> Le 16/03/2021 à 04:17, Jordan Niethe a écrit : >> > setup_text_poke_area() is a late init call so it runs before >> > mark_rodata_ro() and after the init calls. This lets all the init code >> > patching simply write to their locations. In the future, kprobes is >> > going to allocate its instruction pages RO which means they will need >> > setup_text__poke_area() to have been already called for their code >> > patching. However, init_kprobes() (which allocates and patches some >> > instruction pages) is an early init call so it happens before >> > setup_text__poke_area(). >> > >> > start_kernel() calls poking_init() before any of the init calls. On >> > powerpc, poking_init() is currently a nop. setup_text_poke_area() relies >> > on kernel virtual memory, cpu hotplug and per_cpu_areas being setup. >> > setup_per_cpu_areas(), boot_cpu_hotplug_init() and mm_init() are called >> > before poking_init(). >> > >> > Turn setup_text_poke_area() into poking_init(). >> > >> > Signed-off-by: Jordan Niethe >> > --- >> > v9: New to series >> > --- >> > arch/powerpc/lib/code-patching.c | 12 >> > 1 file changed, 4 insertions(+), 8 deletions(-) >> > >> > diff --git a/arch/powerpc/lib/code-patching.c >> > b/arch/powerpc/lib/code-patching.c >> > index 2333625b5e31..b28afa1133db 100644 >> > --- a/arch/powerpc/lib/code-patching.c >> > +++ b/arch/powerpc/lib/code-patching.c >> > @@ -65,14 +65,11 @@ static int text_area_cpu_down(unsigned int cpu) >> > } >> > >> > /* >> > - * Run as a late init call. This allows all the boot time patching to be >> > done >> > - * simply by patching the code, and then we're called here prior to >> > - * mark_rodata_ro(), which happens after all init calls are run. Although >> > - * BUG_ON() is rude, in this case it should only happen if ENOMEM, and we >> > judge >> > - * it as being preferable to a kernel that will crash later when someone >> > tries >> > - * to use patch_instruction(). >> > + * Although BUG_ON() is rude, in this case it should only happen if >> > ENOMEM, and >> > + * we judge it as being preferable to a kernel that will crash later when >> > + * someone tries to use patch_instruction(). >> >> Please use WARN_ON(), see why at >> https://www.kernel.org/doc/html/latest/process/deprecated.html > Ok I can include a change to WARN_ON() as a separate patch. I'm not convinced we should change this to a WARN_ON. Being able to patch the kernel text is not optional. Patching jump labels has no ability to return an error, and the code that uses them has no concept of the jump label not taking the correct polarity. Silently failing the patch is like randomly flipping an if condition somewhere in the kernel and hoping that everything will continue working. cheers
[PATCH 34/36] scsi: ibmvscsi: ibmvfc: Fix a bunch of misdocumentation
Fixes the following W=1 kernel build warning(s):
drivers/scsi/ibmvscsi/ibmvfc.c:331: warning: Function parameter or member
'vhost' not described in 'ibmvfc_get_err_result'
drivers/scsi/ibmvscsi/ibmvfc.c:653: warning: Excess function parameter
'job_step' description in 'ibmvfc_del_tgt'
drivers/scsi/ibmvscsi/ibmvfc.c:773: warning: Function parameter or member
'queue' not described in 'ibmvfc_init_event_pool'
drivers/scsi/ibmvscsi/ibmvfc.c:773: warning: Function parameter or member
'size' not described in 'ibmvfc_init_event_pool'
drivers/scsi/ibmvscsi/ibmvfc.c:823: warning: Function parameter or member
'queue' not described in 'ibmvfc_free_event_pool'
drivers/scsi/ibmvscsi/ibmvfc.c:1413: warning: Function parameter or member
'vhost' not described in 'ibmvfc_gather_partition_info'
drivers/scsi/ibmvscsi/ibmvfc.c:1483: warning: Function parameter or member
'queue' not described in 'ibmvfc_get_event'
drivers/scsi/ibmvscsi/ibmvfc.c:1483: warning: Excess function parameter
'vhost' description in 'ibmvfc_get_event'
drivers/scsi/ibmvscsi/ibmvfc.c:1630: warning: Function parameter or member 't'
not described in 'ibmvfc_timeout'
drivers/scsi/ibmvscsi/ibmvfc.c:1630: warning: Excess function parameter 'evt'
description in 'ibmvfc_timeout'
drivers/scsi/ibmvscsi/ibmvfc.c:1893: warning: Function parameter or member
'shost' not described in 'ibmvfc_queuecommand'
drivers/scsi/ibmvscsi/ibmvfc.c:1893: warning: Excess function parameter 'done'
description in 'ibmvfc_queuecommand'
drivers/scsi/ibmvscsi/ibmvfc.c:2324: warning: Function parameter or member
'rport' not described in 'ibmvfc_match_rport'
drivers/scsi/ibmvscsi/ibmvfc.c:2324: warning: Excess function parameter
'device' description in 'ibmvfc_match_rport'
drivers/scsi/ibmvscsi/ibmvfc.c:3133: warning: Function parameter or member
'evt_doneq' not described in 'ibmvfc_handle_crq'
drivers/scsi/ibmvscsi/ibmvfc.c:3317: warning: Excess function parameter
'reason' description in 'ibmvfc_change_queue_depth'
drivers/scsi/ibmvscsi/ibmvfc.c:3390: warning: Function parameter or member
'attr' not described in 'ibmvfc_show_log_level'
drivers/scsi/ibmvscsi/ibmvfc.c:3413: warning: Function parameter or member
'attr' not described in 'ibmvfc_store_log_level'
drivers/scsi/ibmvscsi/ibmvfc.c:3413: warning: Function parameter or member
'count' not described in 'ibmvfc_store_log_level'
drivers/scsi/ibmvscsi/ibmvfc.c:4121: warning: Function parameter or member
'done' not described in '__ibmvfc_tgt_get_implicit_logout_evt'
drivers/scsi/ibmvscsi/ibmvfc.c:4438: warning: Function parameter or member 't'
not described in 'ibmvfc_adisc_timeout'
drivers/scsi/ibmvscsi/ibmvfc.c:4438: warning: Excess function parameter 'tgt'
description in 'ibmvfc_adisc_timeout'
drivers/scsi/ibmvscsi/ibmvfc.c:4641: warning: Function parameter or member
'target' not described in 'ibmvfc_alloc_target'
drivers/scsi/ibmvscsi/ibmvfc.c:4641: warning: Excess function parameter
'scsi_id' description in 'ibmvfc_alloc_target'
drivers/scsi/ibmvscsi/ibmvfc.c:5068: warning: Function parameter or member
'evt' not described in 'ibmvfc_npiv_logout_done'
drivers/scsi/ibmvscsi/ibmvfc.c:5068: warning: Excess function parameter
'vhost' description in 'ibmvfc_npiv_logout_done'
Cc: Tyrel Datwyler
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: Brian King
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Lee Jones
---
drivers/scsi/ibmvscsi/ibmvfc.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index a38d9d5d90ba3..a7a9b647ea178 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -326,6 +326,7 @@ static const char *ibmvfc_get_cmd_error(u16 status, u16
error)
/**
* ibmvfc_get_err_result - Find the scsi status to return for the fcp response
+ * @vhost: ibmvfc host struct
* @vfc_cmd: ibmvfc command struct
*
* Return value:
@@ -650,8 +651,6 @@ static void ibmvfc_reinit_host(struct ibmvfc_host *vhost)
/**
* ibmvfc_del_tgt - Schedule cleanup and removal of the target
* @tgt: ibmvfc target struct
- * @job_step: job step to perform
- *
**/
static void ibmvfc_del_tgt(struct ibmvfc_target *tgt)
{
@@ -768,6 +767,8 @@ static int ibmvfc_send_crq_init_complete(struct ibmvfc_host
*vhost)
/**
* ibmvfc_init_event_pool - Allocates and initializes the event pool for a host
* @vhost: ibmvfc host who owns the event pool
+ * @queue: ibmvfc queue struct
+ * @size: pool size
*
* Returns zero on success.
**/
@@ -820,6 +821,7 @@ static int ibmvfc_init_event_pool(struct ibmvfc_host *vhost,
/**
* ibmvfc_free_event_pool - Frees memory of the event pool of a host
* @vhost: ibmvfc host who owns the event pool
+ * @queue: ibmvfc queue struct
*
**/
static void
[PATCH 33/36] scsi: ibmvscsi: Fix a bunch of kernel-doc related issues
Fixes the following W=1 kernel build warning(s): drivers/scsi/ibmvscsi/ibmvscsi.c:143: warning: Function parameter or member 'hostdata' not described in 'ibmvscsi_release_crq_queue' drivers/scsi/ibmvscsi/ibmvscsi.c:143: warning: Function parameter or member 'max_requests' not described in 'ibmvscsi_release_crq_queue' drivers/scsi/ibmvscsi/ibmvscsi.c:143: warning: expecting prototype for release_crq_queue(). Prototype was for ibmvscsi_release_crq_queue() instead drivers/scsi/ibmvscsi/ibmvscsi.c:286: warning: expecting prototype for reset_crq_queue(). Prototype was for ibmvscsi_reset_crq_queue() instead drivers/scsi/ibmvscsi/ibmvscsi.c:328: warning: Function parameter or member 'max_requests' not described in 'ibmvscsi_init_crq_queue' drivers/scsi/ibmvscsi/ibmvscsi.c:328: warning: expecting prototype for initialize_crq_queue(). Prototype was for ibmvscsi_init_crq_queue() instead drivers/scsi/ibmvscsi/ibmvscsi.c:414: warning: expecting prototype for reenable_crq_queue(). Prototype was for ibmvscsi_reenable_crq_queue() instead drivers/scsi/ibmvscsi/ibmvscsi.c:536: warning: expecting prototype for ibmvscsi_free(). Prototype was for free_event_struct() instead drivers/scsi/ibmvscsi/ibmvscsi.c:558: warning: expecting prototype for get_evt_struct(). Prototype was for get_event_struct() instead drivers/scsi/ibmvscsi/ibmvscsi.c:587: warning: Function parameter or member 'evt_struct' not described in 'init_event_struct' drivers/scsi/ibmvscsi/ibmvscsi.c:587: warning: Excess function parameter 'evt' description in 'init_event_struct' drivers/scsi/ibmvscsi/ibmvscsi.c:608: warning: Function parameter or member 'cmd' not described in 'set_srp_direction' drivers/scsi/ibmvscsi/ibmvscsi.c:608: warning: Function parameter or member 'srp_cmd' not described in 'set_srp_direction' drivers/scsi/ibmvscsi/ibmvscsi.c:608: warning: Function parameter or member 'numbuf' not described in 'set_srp_direction' drivers/scsi/ibmvscsi/ibmvscsi.c:641: warning: Function parameter or member 'evt_struct' not described in 'unmap_cmd_data' drivers/scsi/ibmvscsi/ibmvscsi.c:683: warning: Function parameter or member 'evt_struct' not described in 'map_sg_data' drivers/scsi/ibmvscsi/ibmvscsi.c:757: warning: Function parameter or member 'evt_struct' not described in 'map_data_for_srp_cmd' drivers/scsi/ibmvscsi/ibmvscsi.c:783: warning: Function parameter or member 'error_code' not described in 'purge_requests' drivers/scsi/ibmvscsi/ibmvscsi.c:846: warning: Function parameter or member 't' not described in 'ibmvscsi_timeout' drivers/scsi/ibmvscsi/ibmvscsi.c:846: warning: Excess function parameter 'evt_struct' description in 'ibmvscsi_timeout' drivers/scsi/ibmvscsi/ibmvscsi.c:1043: warning: Function parameter or member 'cmnd' not described in 'ibmvscsi_queuecommand_lck' drivers/scsi/ibmvscsi/ibmvscsi.c:1043: warning: expecting prototype for ibmvscsi_queue(). Prototype was for ibmvscsi_queuecommand_lck() instead drivers/scsi/ibmvscsi/ibmvscsi.c:1351: warning: expecting prototype for init_host(). Prototype was for enable_fast_fail() instead drivers/scsi/ibmvscsi/ibmvscsi.c:1464: warning: Function parameter or member 'hostdata' not described in 'init_adapter' drivers/scsi/ibmvscsi/ibmvscsi.c:1475: warning: Function parameter or member 'evt_struct' not described in 'sync_completion' drivers/scsi/ibmvscsi/ibmvscsi.c:1488: warning: Function parameter or member 'cmd' not described in 'ibmvscsi_eh_abort_handler' drivers/scsi/ibmvscsi/ibmvscsi.c:1488: warning: expecting prototype for ibmvscsi_abort(). Prototype was for ibmvscsi_eh_abort_handler() instead drivers/scsi/ibmvscsi/ibmvscsi.c:1627: warning: Function parameter or member 'cmd' not described in 'ibmvscsi_eh_device_reset_handler' drivers/scsi/ibmvscsi/ibmvscsi.c:1893: warning: Excess function parameter 'reason' description in 'ibmvscsi_change_queue_depth' drivers/scsi/ibmvscsi/ibmvscsi.c:2221: warning: Function parameter or member 'vdev' not described in 'ibmvscsi_probe' drivers/scsi/ibmvscsi/ibmvscsi.c:2221: warning: Function parameter or member 'id' not described in 'ibmvscsi_probe' drivers/scsi/ibmvscsi/ibmvscsi.c:2221: warning: expecting prototype for Called by bus code for each adapter(). Prototype was for ibmvscsi_probe() instead drivers/scsi/ibmvscsi/ibmvscsi.c:2381: warning: cannot understand function prototype: 'const struct vio_device_id ibmvscsi_device_table[] = ' Cc: Tyrel Datwyler Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Cc: Colin DeVilbiss Cc: Santiago Leon Cc: Dave Boutcher Cc: linux-s...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Lee Jones --- drivers/scsi/ibmvscsi/ibmvscsi.c | 70 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c index 77fafb1bc173a..9ffd71e425f90 100644 ---
Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
On 17.03.21 02:52, Kefeng Wang wrote:
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/arch/alpha/mm/init.c b/arch/alpha/mm/init.c
index 3c42b3147fd6..a97650a618f1 100644
--- a/arch/alpha/mm/init.c
+++ b/arch/alpha/mm/init.c
@@ -282,5 +282,4 @@ mem_init(void)
set_max_mapnr(max_low_pfn);
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
memblock_free_all();
- mem_init_print_info(NULL);
}
diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
index ce07e697916c..33832e36bdb7 100644
--- a/arch/arc/mm/init.c
+++ b/arch/arc/mm/init.c
@@ -194,7 +194,6 @@ void __init mem_init(void)
{
memblock_free_all();
highmem_init();
- mem_init_print_info(NULL);
}
#ifdef CONFIG_HIGHMEM
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 828a2561b229..7022b7b5c400 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -316,8 +316,6 @@ void __init mem_init(void)
free_highpages();
- mem_init_print_info(NULL);
-
/*
* Check boundaries twice: Some fundamental inconsistencies can
* be detected at build time already.
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 3685e12aba9b..e8f29a0bb2f1 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -491,8 +491,6 @@ void __init mem_init(void)
/* this will put all unused low memory onto the freelists */
memblock_free_all();
- mem_init_print_info(NULL);
-
/*
* Check boundaries twice: Some fundamental inconsistencies can be
* detected at build time already.
diff --git a/arch/csky/mm/init.c b/arch/csky/mm/init.c
index 894050a8ce09..bf2004aa811a 100644
--- a/arch/csky/mm/init.c
+++ b/arch/csky/mm/init.c
@@ -107,7 +107,6 @@ void __init mem_init(void)
free_highmem_page(page);
}
#endif
- mem_init_print_info(NULL);
}
void free_initmem(void)
diff --git a/arch/h8300/mm/init.c b/arch/h8300/mm/init.c
index 1f3b345d68b9..f7bf4693e3b2 100644
--- a/arch/h8300/mm/init.c
+++ b/arch/h8300/mm/init.c
@@ -98,6 +98,4 @@ void __init mem_init(void)
/* this will put all low memory onto the freelists */
memblock_free_all();
-
- mem_init_print_info(NULL);
}
diff --git a/arch/hexagon/mm/init.c b/arch/hexagon/mm/init.c
index f2e6c868e477..f01e91e10d95 100644
--- a/arch/hexagon/mm/init.c
+++ b/arch/hexagon/mm/init.c
@@ -55,7 +55,6 @@ void __init mem_init(void)
{
/* No idea where this is actually declared. Seems to evade LXR. */
memblock_free_all();
- mem_init_print_info(NULL);
/*
* To-Do: someone somewhere should wipe out the bootmem map
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index 16d0d7d22657..83280e2df807 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -659,7 +659,6 @@ mem_init (void)
set_max_mapnr(max_low_pfn);
high_memory = __va(max_low_pfn * PAGE_SIZE);
memblock_free_all();
- mem_init_print_info(NULL);
/*
* For fsyscall entrpoints with no light-weight handler, use the
ordinary
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index 14c1e541451c..1759ab875d47 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -153,5 +153,4 @@ void __init mem_init(void)
/* this will put all memory onto the freelists */
memblock_free_all();
init_pointer_tables();
- mem_init_print_info(NULL);
Re: [PATCH] powerpc: arch/powerpc/kernel/setup_64.c - cleanup warnings
Daniel Axtens writes:
> "heying (H)" writes:
>
>> Thank you for your reply.
>>
>> 在 2021/3/17 11:04, Daniel Axtens 写道:
>>> Hi He Ying,
>>>
>>> Thank you for this patch.
>>>
>>> I'm not sure what the precise rules for Fixes are, but I wonder if this
>>> should have:
>>>
>>> Fixes: 9a32a7e78bd0 ("powerpc/64s: flush L1D after user accesses")
>>> Fixes: f79643787e0a ("powerpc/64s: flush L1D on kernel entry")
>>
>> Is that necessary for warning cleanups? I thought 'Fixes' tags are
>> needed only for
>>
>> bugfix patches. Can someone tell me whether I am right?
>
> Yeah, I'm not sure either. Hopefully mpe will let us know.
It's not necessary to add a Fixes tag for a patch like this, but you can
add one if you think it's important that the fix gets backported.
I don't think the cleanups in this case are that important, so I
wouldn't bother with a Fixes tag.
cheers
Re: [PATCH -next] powerpc: kernel/time.c - cleanup warnings
Le 17/03/2021 à 11:34, He Ying a écrit :
We found these warnings in arch/powerpc/kernel/time.c as follows:
warning: symbol 'decrementer_max' was not declared. Should it be static?
warning: symbol 'rtc_lock' was not declared. Should it be static?
warning: symbol 'dtl_consumer' was not declared. Should it be static?
Declare 'decrementer_max' in arch/powerpc/include/asm/time.h. And include
proper header in which 'rtc_lock' is declared. Move 'dtl_consumer'
definition behind "include " because 'dtl_consumer' is declared
there.
Reported-by: Hulk Robot
Signed-off-by: He Ying
---
arch/powerpc/include/asm/time.h | 1 +
arch/powerpc/kernel/time.c | 7 +++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 8dd3cdb25338..2cd2b50bedda 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -22,6 +22,7 @@ extern unsigned long tb_ticks_per_jiffy;
extern unsigned long tb_ticks_per_usec;
extern unsigned long tb_ticks_per_sec;
extern struct clock_event_device decrementer_clockevent;
+extern u64 decrementer_max;
extern void generic_calibrate_decr(void);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index b67d93a609a2..409967713ca6 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
I don't think that's the good place. It has no link to powerpc, it is only by chance that it has the
same name.
As rtc_lock is defined in powerpc time.c, I think you should declare it in
powerpc asm/time.h
#include
#include
@@ -150,10 +151,6 @@ bool tb_invalid;
u64 __cputime_usec_factor;
EXPORT_SYMBOL(__cputime_usec_factor);
-#ifdef CONFIG_PPC_SPLPAR
-void (*dtl_consumer)(struct dtl_entry *, u64);
-#endif
-
static void calc_cputime_factors(void)
{
struct div_result res;
@@ -179,6 +176,8 @@ static inline unsigned long read_spurr(unsigned long tb)
#include
+void (*dtl_consumer)(struct dtl_entry *, u64);
+
/*
* Scan the dispatch trace log and count up the stolen time.
* Should be called with interrupts disabled.
Re: Advice needed on SMP regression after cpu_core_mask change
On 3/17/21 12:30 PM, Cédric Le Goater wrote:
On 3/17/21 2:00 PM, Daniel Henrique Barboza wrote:
Hello,
Patch 4bce545903fa ("powerpc/topology: Update topology_core_cpumask") introduced
a regression in both upstream and RHEL downstream kernels [1]. The assumption
made
in the commit:
"Further analysis shows that cpu_core_mask and cpu_cpu_mask for any CPU would be
equal on Power"
Doesn't seem to be true. After this commit, QEMU is now unable to set single
NUMA
node SMP topologies such as:
-smp 8,maxcpus=8,cores=2,threads=2,sockets=2
lscpu will give the following output in this case:
# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Model: 2.2 (pvr 004e 1202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: KVM
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
NUMA node0 CPU(s): 0-7
This is happening because the macro cpu_cpu_mask(cpu) expands to
cpumask_of_node(cpu_to_node(cpu)), which in turn expands to
node_to_cpumask_map[node].
node_to_cpumask_map is a NUMA array that maps CPUs to NUMA nodes (Aneesh is on
CC to
correct me if I'm wrong). We're now associating sockets to NUMA nodes directly.
If I add a second NUMA node then I can get the intended smp topology:
-smp 8,maxcpus=8,cores=2,threads=2,sockets=2
-numa node,memdev=mem0,cpus=0-3,nodeid=0 \
-numa node,memdev=mem1,cpus=4-7,nodeid=1 \
# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 2
NUMA node(s): 2
Model: 2.2 (pvr 004e 1202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: KVM
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
NUMA node0 CPU(s): 0-3
NUMA node1 CPU(s): 4-7
However, if I try a single socket with multiple NUMA nodes topology, which is
the case
of Power10, e.g.:
-smp 8,maxcpus=8,cores=4,threads=2,sockets=1
-numa node,memdev=mem0,cpus=0-3,nodeid=0 \
-numa node,memdev=mem1,cpus=4-7,nodeid=1 \
This is the result:
# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 2
NUMA node(s): 2
Model: 2.2 (pvr 004e 1202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: KVM
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
NUMA node0 CPU(s): 0-3
NUMA node1 CPU(s): 4-7
This confirms my suspicions that, at this moment, we're making sockets == NUMA
nodes.
Yes. I don't think we can do better on PAPR and the above examples
seem to confirm that the "sockets" definition is simply ignored.
Cedric, the reason I'm CCing you is because this is related to ibm,chip-id. The
commit
after the one that caused the regression, 4ca234a9cbd7c3a65 ("powerpc/smp: Stop
updating
cpu_core_mask"), is erasing the code that calculated cpu_core_mask.
cpu_core_mask, despite
its shortcomings that caused its removal, was giving a precise SMP topology.
And it was
using physical_package_id/'ibm,chip-id' for that.
ibm,chip-id is a no-no on pSeries. I guess this is inherent to PAPR which
is hiding a lot of the underlying HW and topology. May be we are trying
to reconcile two orthogonal views of machine virtualization ...
Checking in QEMU I can say that the ibm,chip-id calculation is the only place
in the code
that cares about cores per socket information. The kernel is now ignoring that,
starting
on 4bce545903fa, and now QEMU is unable to provide this info to the guest.
If we're not going to use ibm,chip-id any longer, which seems sensible given
that PAPR does
not declare it, we need another way of letting the guest know how much cores
per socket
we want.
The RTAS call "ibm,get-system-parameter" with token "Processor Module
Information" returns that kind of information :
2 byte binary number (N) of module types followed by N module specifiers of
the form:
2 byte binary number (M) of sockets of this module type
2 byte binary number (L) of chips per this module type
2 byte binary number (K) of cores per chip in this module type.
See the values in these sysfs files :
cat /sys/devices/hv_24x7/interface/{sockets,chipspersocket,coresperchip}
But I am afraid these are host level information and not guest/LPAR.
I believe there might be some sort of reasoning behind not having this on
PAPR, but I'll say in advance that the virtual machine should act as the
real hardware, as close as possible. This is the kind of hcall that could
be used in this situation.
I didn't find any LPAR level properties or hcalls in the PAPR document.
They need to be specified.
or
We
Re: [PATCH] powerpc: kernel: Trivial typo fix in the file kgdb.c
On 3/17/21 2:04 AM, Bhaskar Chowdhury wrote: > > s/procesing/processing/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > arch/powerpc/kernel/kgdb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c > index 409080208a6c..7dd2ad3603ad 100644 > --- a/arch/powerpc/kernel/kgdb.c > +++ b/arch/powerpc/kernel/kgdb.c > @@ -376,7 +376,7 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long > pc) > } > > /* > - * This function does PowerPC specific procesing for interfacing to gdb. > + * This function does PowerPC specific processing for interfacing to gdb. > */ > int kgdb_arch_handle_exception(int vector, int signo, int err_code, > char *remcom_in_buffer, char *remcom_out_buffer, > -- -- ~Randy
Re: [PATCH v3 19/41] KVM: PPC: Book3S HV P9: Stop handling hcalls in real-mode in the P9 path
Nicholas Piggin writes:
> In the interest of minimising the amount of code that is run in
> "real-mode", don't handle hcalls in real mode in the P9 path.
>
> POWER8 and earlier are much more expensive to exit from HV real mode
> and switch to host mode, because on those processors HV interrupts get
> to the hypervisor with the MMU off, and the other threads in the core
> need to be pulled out of the guest, and SLBs all need to be saved,
> ERATs invalidated, and host SLB reloaded before the MMU is re-enabled
> in host mode. Hash guests also require a lot of hcalls to run. The
> XICS interrupt controller requires hcalls to run.
>
> By contrast, POWER9 has independent thread switching, and in radix mode
> the hypervisor is already in a host virtual memory mode when the HV
> interrupt is taken. Radix + xive guests don't need hcalls to handle
> interrupts or manage translations.
>
> So it's much less important to handle hcalls in real mode in P9.
>
> Signed-off-by: Nicholas Piggin
> ---
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 497f216ad724..1f2ba8955c6a 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -1147,7 +1147,7 @@ int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu)
> * This has to be done early, not in kvmppc_pseries_do_hcall(), so
> * that the cede logic in kvmppc_run_single_vcpu() works properly.
> */
> -static void kvmppc_nested_cede(struct kvm_vcpu *vcpu)
> +static void kvmppc_cede(struct kvm_vcpu *vcpu)
The comment above needs to be updated I think.
> {
> vcpu->arch.shregs.msr |= MSR_EE;
> vcpu->arch.ceded = 1;
> @@ -1403,9 +1403,15 @@ static int kvmppc_handle_exit_hv(struct kvm_vcpu *vcpu,
> /* hcall - punt to userspace */
> int i;
>
> - /* hypercall with MSR_PR has already been handled in rmode,
> - * and never reaches here.
> - */
> + if (unlikely(vcpu->arch.shregs.msr & MSR_PR)) {
> + /*
> + * Guest userspace executed sc 1, reflect it back as a
> + * privileged program check interrupt.
> + */
> + kvmppc_core_queue_program(vcpu, SRR1_PROGPRIV);
> + r = RESUME_GUEST;
> + break;
> + }
>
> run->papr_hcall.nr = kvmppc_get_gpr(vcpu, 3);
> for (i = 0; i < 9; ++i)
> @@ -3740,15 +3746,36 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu
> *vcpu, u64 time_limit,
> /* H_CEDE has to be handled now, not later */
> if (trap == BOOK3S_INTERRUPT_SYSCALL && !vcpu->arch.nested &&
> kvmppc_get_gpr(vcpu, 3) == H_CEDE) {
> - kvmppc_nested_cede(vcpu);
> + kvmppc_cede(vcpu);
> kvmppc_set_gpr(vcpu, 3, 0);
> trap = 0;
> }
> } else {
> kvmppc_xive_push_vcpu(vcpu);
> trap = kvmhv_load_hv_regs_and_go(vcpu, time_limit, lpcr);
> - kvmppc_xive_pull_vcpu(vcpu);
> + /* H_CEDE has to be handled now, not later */
> + /* XICS hcalls must be handled before xive is pulled */
> + if (trap == BOOK3S_INTERRUPT_SYSCALL &&
> + !(vcpu->arch.shregs.msr & MSR_PR)) {
> + unsigned long req = kvmppc_get_gpr(vcpu, 3);
>
> + if (req == H_CEDE) {
> + kvmppc_cede(vcpu);
> + kvmppc_xive_cede_vcpu(vcpu); /* may un-cede */
> + kvmppc_set_gpr(vcpu, 3, 0);
> + trap = 0;
> + }
> + if (req == H_EOI || req == H_CPPR ||
> + req == H_IPI || req == H_IPOLL ||
> + req == H_XIRR || req == H_XIRR_X) {
> + unsigned long ret;
> +
> + ret = kvmppc_xive_xics_hcall(vcpu, req);
> + kvmppc_set_gpr(vcpu, 3, ret);
> + trap = 0;
> + }
> + }
I tried running L2 with xive=off and this code slows down the boot
considerably. I think we're missing a !vcpu->arch.nested in the
conditional.
This may also be missing these checks from kvmppc_pseries_do_hcall:
if (kvmppc_xics_enabled(vcpu)) {
if (xics_on_xive()) {
ret = H_NOT_AVAILABLE;
return RESUME_GUEST;
}
ret = kvmppc_xics_hcall(vcpu, req);
(...)
For H_CEDE there might be a similar situation since we're shadowing the
code above that runs after H_ENTER_NESTED by setting trap to 0 here.
> + kvmppc_xive_pull_vcpu(vcpu);
> }
>
> vcpu->arch.slb_max = 0;
> @@
Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 17, 2021 at 01:42:07PM +, Konrad Rzeszutek Wilk wrote:
> > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > - if (!io_tlb_alloc_size)
> > > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > > - __func__, alloc_size, PAGE_SIZE);
> >
> > Shouldn't this be converted to:
> > mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > if (...)
> >
> > Seems that it got lost in the search and replace?
>
> Yes, I messed that up during the rebase. That being said it magically
> gets fixed in the next patch..
Yes. However if someone does a bisection they are going to be mighty unhappy
with you.
Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
On Wed, Mar 17, 2021 at 01:51:56PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> > On Wed, Mar 17, 2021 at 01:42:07PM +, Konrad Rzeszutek Wilk wrote:
> > > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > > - if (!io_tlb_alloc_size)
> > > > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > > > - __func__, alloc_size, PAGE_SIZE);
> > >
> > > Shouldn't this be converted to:
> > > mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > if (...)
> > >
> > > Seems that it got lost in the search and replace?
> >
> > Yes, I messed that up during the rebase. That being said it magically
> > gets fixed in the next patch..
>
> Yes. However if someone does a bisection they are going to be mighty unhappy
> with you.
Sure, I was planning on fixing it anyway. Just waiting for feedback
on the rest of the patches before doing a respin.
Re: [PATCH v3 19/41] KVM: PPC: Book3S HV P9: Stop handling hcalls in real-mode in the P9 path
Excerpts from Fabiano Rosas's message of March 18, 2021 2:22 am:
> Nicholas Piggin writes:
>
>> In the interest of minimising the amount of code that is run in
>> "real-mode", don't handle hcalls in real mode in the P9 path.
>>
>> POWER8 and earlier are much more expensive to exit from HV real mode
>> and switch to host mode, because on those processors HV interrupts get
>> to the hypervisor with the MMU off, and the other threads in the core
>> need to be pulled out of the guest, and SLBs all need to be saved,
>> ERATs invalidated, and host SLB reloaded before the MMU is re-enabled
>> in host mode. Hash guests also require a lot of hcalls to run. The
>> XICS interrupt controller requires hcalls to run.
>>
>> By contrast, POWER9 has independent thread switching, and in radix mode
>> the hypervisor is already in a host virtual memory mode when the HV
>> interrupt is taken. Radix + xive guests don't need hcalls to handle
>> interrupts or manage translations.
>>
>> So it's much less important to handle hcalls in real mode in P9.
>>
>> Signed-off-by: Nicholas Piggin
>> ---
>
>
>
>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>> index 497f216ad724..1f2ba8955c6a 100644
>> --- a/arch/powerpc/kvm/book3s_hv.c
>> +++ b/arch/powerpc/kvm/book3s_hv.c
>> @@ -1147,7 +1147,7 @@ int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu)
>> * This has to be done early, not in kvmppc_pseries_do_hcall(), so
>> * that the cede logic in kvmppc_run_single_vcpu() works properly.
>> */
>> -static void kvmppc_nested_cede(struct kvm_vcpu *vcpu)
>> +static void kvmppc_cede(struct kvm_vcpu *vcpu)
>
> The comment above needs to be updated I think.
>
>> {
>> vcpu->arch.shregs.msr |= MSR_EE;
>> vcpu->arch.ceded = 1;
>> @@ -1403,9 +1403,15 @@ static int kvmppc_handle_exit_hv(struct kvm_vcpu
>> *vcpu,
>> /* hcall - punt to userspace */
>> int i;
>>
>> -/* hypercall with MSR_PR has already been handled in rmode,
>> - * and never reaches here.
>> - */
>> +if (unlikely(vcpu->arch.shregs.msr & MSR_PR)) {
>> +/*
>> + * Guest userspace executed sc 1, reflect it back as a
>> + * privileged program check interrupt.
>> + */
>> +kvmppc_core_queue_program(vcpu, SRR1_PROGPRIV);
>> +r = RESUME_GUEST;
>> +break;
>> +}
>>
>> run->papr_hcall.nr = kvmppc_get_gpr(vcpu, 3);
>> for (i = 0; i < 9; ++i)
>> @@ -3740,15 +3746,36 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu
>> *vcpu, u64 time_limit,
>> /* H_CEDE has to be handled now, not later */
>> if (trap == BOOK3S_INTERRUPT_SYSCALL && !vcpu->arch.nested &&
>> kvmppc_get_gpr(vcpu, 3) == H_CEDE) {
>> -kvmppc_nested_cede(vcpu);
>> +kvmppc_cede(vcpu);
>> kvmppc_set_gpr(vcpu, 3, 0);
>> trap = 0;
>> }
>> } else {
>> kvmppc_xive_push_vcpu(vcpu);
>> trap = kvmhv_load_hv_regs_and_go(vcpu, time_limit, lpcr);
>> -kvmppc_xive_pull_vcpu(vcpu);
>> +/* H_CEDE has to be handled now, not later */
>> +/* XICS hcalls must be handled before xive is pulled */
>> +if (trap == BOOK3S_INTERRUPT_SYSCALL &&
>> +!(vcpu->arch.shregs.msr & MSR_PR)) {
>> +unsigned long req = kvmppc_get_gpr(vcpu, 3);
>>
>> +if (req == H_CEDE) {
>> +kvmppc_cede(vcpu);
>> +kvmppc_xive_cede_vcpu(vcpu); /* may un-cede */
>> +kvmppc_set_gpr(vcpu, 3, 0);
>> +trap = 0;
>> +}
>> +if (req == H_EOI || req == H_CPPR ||
>> +req == H_IPI || req == H_IPOLL ||
>> +req == H_XIRR || req == H_XIRR_X) {
>> +unsigned long ret;
>> +
>> +ret = kvmppc_xive_xics_hcall(vcpu, req);
>> +kvmppc_set_gpr(vcpu, 3, ret);
>> +trap = 0;
>> +}
>> +}
>
> I tried running L2 with xive=off and this code slows down the boot
> considerably. I think we're missing a !vcpu->arch.nested in the
> conditional.
You might be right, the real mode handlers never run if nested is set
so none of these should run I think.
>
> This may also be missing these checks from kvmppc_pseries_do_hcall:
>
> if (kvmppc_xics_enabled(vcpu)) {
> if (xics_on_xive()) {
> ret = H_NOT_AVAILABLE;
> return RESUME_GUEST;
> }
> ret = kvmppc_xics_hcall(vcpu, req);
>
Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
On Wed, Mar 17, 2021 at 06:57:42PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 17, 2021 at 01:51:56PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> > > On Wed, Mar 17, 2021 at 01:42:07PM +, Konrad Rzeszutek Wilk wrote:
> > > > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > > > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > > > - if (!io_tlb_alloc_size)
> > > > > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > > > > - __func__, alloc_size, PAGE_SIZE);
> > > >
> > > > Shouldn't this be converted to:
> > > > mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > > if (...)
> > > >
> > > > Seems that it got lost in the search and replace?
> > >
> > > Yes, I messed that up during the rebase. That being said it magically
> > > gets fixed in the next patch..
> >
> > Yes. However if someone does a bisection they are going to be mighty unhappy
> > with you.
>
> Sure, I was planning on fixing it anyway. Just waiting for feedback
> on the rest of the patches before doing a respin.
I put the patches up-to this one on :
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb
devel/for-linus-5.13
Would you be OK rebasing on top of that and sending the patches?
Juergen, would you be OK testing that branch on your Xen setup?
Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
On 3/16/21 6:52 PM, Kefeng Wang wrote: > 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 It's not a big deal but you might want to say something like: Acked-by: Dave Hansen # x86 bits Just to make it clear that I didn't look at the alpha bits at all. :)
Re: [PATCH 4/4] tools/perf: Support pipeline stage cycles for powerpc
On 16-Mar-2021, at 4:48 AM, Jiri Olsa wrote:On Mon, Mar 15, 2021 at 01:22:09PM +0530, Athira Rajeev wrote:SNIP++static char *setup_dynamic_sort_keys(char *str)+{+ unsigned int j;++ if (sort__mode == SORT_MODE__MEMORY)+ for (j = 0; j < ARRAY_SIZE(dynamic_sort_keys_mem); j++)+ if (arch_support_dynamic_key(dynamic_sort_keys_mem[j])) {+str = suffix_if_not_in(dynamic_sort_keys_mem[j], str);+if (str == NULL)+ return str;+ }++ return str;+}+static int __setup_sorting(struct evlist *evlist){ char *str;@@ -3050,6 +3085,12 @@ static int __setup_sorting(struct evlist *evlist) } }+ str = setup_dynamic_sort_keys(str);+ if (str == NULL) {+ pr_err("Not enough memory to setup dynamic sort keys");+ return -ENOMEM;+ }hum, so this is basicaly overloading the default_mem_sort_order forarchitecture, right?then I think it'd be easier just overload default_mem_sort_order directlyI was thinking more about adding extra (arch specific) loop tosort_dimension__add or somehow add arch's specific stuff tomemory_sort_dimensionsHi Jiri,Above patch was to append additional sort keys to sort order based onsort mode and architecture support. I had initially thought of defining twoorders ( say default_mem_sort_order plus mem_sort_order_pstage ). But ifnew sort keys gets added for mem mode in future, we will need to keepupdating both orders. So preferred the approach of "appending" supported sortkeys to default order.Following your thought on using "sort_dimension__add", I tried below approachwhich is easier. The new sort dimension "p_stage_cyc" is presently only supportedon powerpc. For unsupported platforms, we don't want to display itin the perf report output columns. Hence added check in sort_dimension__add()and skip the sort key incase its not applicable for particular arch.Please help to check if below approach looks fine.diff --git a/tools/perf/arch/powerpc/util/event.c b/tools/perf/arch/powerpc/util/event.cindex b80fbee83b6e..7205767d75eb 100644--- a/tools/perf/arch/powerpc/util/event.c+++ b/tools/perf/arch/powerpc/util/event.c@@ -44,3 +44,10 @@ const char *arch_perf_header_entry__add(const char *se_header) return "Dispatch Cyc"; return se_header; }++int arch_support_sort_key(const char *sort_key)+{+ if (!strcmp(sort_key, "p_stage_cyc"))+ return 1;+ return 0;+}diff --git a/tools/perf/util/event.h b/tools/perf/util/event.hindex 65f89e80916f..612a92aaaefb 100644--- a/tools/perf/util/event.h+++ b/tools/perf/util/event.h@@ -429,5 +429,6 @@ char *get_page_size_name(u64 size, char *str); void arch_perf_parse_sample_weight(struct perf_sample *data, const __u64 *array, u64 type); void arch_perf_synthesize_sample_weight(const struct perf_sample *data, __u64 *array, u64 type); const char *arch_perf_header_entry__add(const char *se_header);+int arch_support_sort_key(const char *sort_key); #endif /* __PERF_RECORD_H */diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.cindex cbb3899e7eca..d8b0b0b43a81 100644--- a/tools/perf/util/sort.c+++ b/tools/perf/util/sort.c@@ -47,6 +47,7 @@ regex_t ignore_callees_regex; int have_ignore_callees = 0; enum sort_mode sort__mode = SORT_MODE__NORMAL; const char *dynamic_headers[] = {"local_ins_lat", "p_stage_cyc"};+const char *arch_specific_sort_keys[] = {"p_stage_cyc"}; /* * Replaces all occurrences of a char used with the:@@ -1837,6 +1838,11 @@ struct sort_dimension { int taken; };+int __weak arch_support_sort_key(const char *sort_key __maybe_unused)+{+ return 0;+}+ const char * __weak arch_perf_header_entry__add(const char *se_header) { return se_header;@@ -2773,6 +2779,18 @@ int sort_dimension__add(struct perf_hpp_list *list, const char *tok, { unsigned int i, j;+ /* Check to see if there are any arch specific+ * sort dimensions not applicable for the current+ * architecture. If so, Skip that sort key since+ * we don't want to display it in the output fields.+ */+ for (j = 0; j < ARRAY_SIZE(arch_specific_sort_keys); j++) {+ if (!strcmp(arch_specific_sort_keys[j], tok) &&+!arch_support_sort_key(tok)) {+ return 0;+ }+ }+ for (i = 0; i < ARRAY_SIZE(common_sort_dimensions); i++) { struct sort_dimension *sd = _sort_dimensions[i];— 2.26.2ThanksAthirajirka
Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
On 2021/3/18 2:48, Dave Hansen wrote: On 3/16/21 6:52 PM, Kefeng Wang wrote: 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 It's not a big deal but you might want to say something like: Acked-by: Dave Hansen # x86 bits Just to make it clear that I didn't look at the alpha bits at all. :) Get it, will be careful, thanks. .
[powerpc:fixes-test] BUILD SUCCESS cc7a0bb058b85ea03db87169c60c7cfdd5d34678
arm eseries_pxa_defconfig powerpc lite5200b_defconfig powerpc ppa8548_defconfig powerpc ebony_defconfig arm footbridge_defconfig mipsbcm47xx_defconfig powerpcmpc7448_hpc2_defconfig xtensa defconfig arm lpc18xx_defconfig sh lboxre2_defconfig alphaallyesconfig powerpc tqm8541_defconfig alphaalldefconfig arm lubbock_defconfig ia64zx1_defconfig sh espt_defconfig arcnsimosci_defconfig parisc allyesconfig powerpcsam440ep_defconfig powerpc mpc8560_ads_defconfig arm ixp4xx_defconfig mipsvocore2_defconfig powerpc mpc5200_defconfig powerpc motionpro_defconfig nios2alldefconfig mips ip27_defconfig xtensa common_defconfig nios2 3c120_defconfig mipsar7_defconfig mipsmaltaup_defconfig arm stm32_defconfig mips ath25_defconfig powerpc64alldefconfig s390 zfcpdump_defconfig microblaze defconfig powerpc cm5200_defconfig sh sh7770_generic_defconfig mipsmaltaup_xpa_defconfig mips malta_kvm_defconfig armlart_defconfig arm spitz_defconfig sh sh7785lcr_32bit_defconfig arm vf610m4_defconfig xtensa alldefconfig arm collie_defconfig shsh7763rdp_defconfig powerpc sbc8548_defconfig arm exynos_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allnoconfig x86_64 randconfig-a006-20210317 x86_64 randconfig-a001-20210317 x86_64 randconfig-a005-20210317 x86_64 randconfig-a004-20210317 x86_64 randconfig-a003-20210317 x86_64 randconfig-a002-20210317 i386 randconfig-a001-20210317 i386 randconfig-a005-20210317 i386 randconfig-a002-20210317 i386 randconfig-a003-20210317 i386 randconfig-a004-20210317 i386 randconfig-a006-20210317 i386 randconfig-a013-20210317 i386 randconfig-a016-20210317 i386 randconfig-a011-20210317 i386 randconfig-a012-20210317 i386 randconfig-a015-20210317 i386 randconfig-a014-20210317 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a011-20210317 x86_64 randconfig-a016-20210317 x86_64 randconfig-a013-20210317 x86_64 randconfig-a014-20210317 x86_64
[powerpc:next-test] BUILD SUCCESS 11aa533b82d5785e0475fd1e2f47db1ccf8f5be4
allnoconfig i386 randconfig-a001-20210317 i386 randconfig-a005-20210317 i386 randconfig-a002-20210317 i386 randconfig-a003-20210317 i386 randconfig-a004-20210317 i386 randconfig-a006-20210317 x86_64 randconfig-a006-20210317 x86_64 randconfig-a001-20210317 x86_64 randconfig-a005-20210317 x86_64 randconfig-a004-20210317 x86_64 randconfig-a003-20210317 x86_64 randconfig-a002-20210317 i386 randconfig-a013-20210317 i386 randconfig-a016-20210317 i386 randconfig-a011-20210317 i386 randconfig-a012-20210317 i386 randconfig-a015-20210317 i386 randconfig-a014-20210317 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a011-20210317 x86_64 randconfig-a016-20210317 x86_64 randconfig-a013-20210317 x86_64 randconfig-a014-20210317 x86_64 randconfig-a015-20210317 x86_64 randconfig-a012-20210317 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[powerpc:merge] BUILD SUCCESS 87d76f542a24ecfa797e9bd3bb56c0f19aabff57
wii_defconfig microblaze defconfig powerpc cm5200_defconfig powerpc storcenter_defconfig sh sh7770_generic_defconfig mipsmaltaup_xpa_defconfig arc haps_hs_defconfig arm vf610m4_defconfig xtensa alldefconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a006-20210317 x86_64 randconfig-a001-20210317 x86_64 randconfig-a005-20210317 x86_64 randconfig-a004-20210317 x86_64 randconfig-a003-20210317 x86_64 randconfig-a002-20210317 i386 randconfig-a001-20210317 i386 randconfig-a005-20210317 i386 randconfig-a002-20210317 i386 randconfig-a003-20210317 i386 randconfig-a004-20210317 i386 randconfig-a006-20210317 i386 randconfig-a013-20210317 i386 randconfig-a016-20210317 i386 randconfig-a011-20210317 i386 randconfig-a012-20210317 i386 randconfig-a015-20210317 i386 randconfig-a014-20210317 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a011-20210317 x86_64 randconfig-a016-20210317 x86_64 randconfig-a013-20210317 x86_64 randconfig-a014-20210317 x86_64 randconfig-a015-20210317 x86_64 randconfig-a012-20210317 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
On 3/16/21 6:52 PM, Kefeng Wang wrote: > 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 Acked-by: Vineet Gupta Thx, -Vineet
Re: Errant readings on LM81 with T2080 SoC
> The polling code is from pre-git times. Like 2005 and earlier. > I'd say it is about time to get rid of it. Any out-of-tree users > had more than 15 years to upstream their code, after all. Parts of the polling mode might be interesting for the atomic_xfer mode maybe? Which is not implemented yet. signature.asc Description: PGP signature
Re: Errant readings on LM81 with T2080 SoC
> Probably depends on the device implementation. I've got multiple other > I2C/SMBUS devices and the LM81 seems to be the one that objects. For the recored, there was just a similar case with a DA9063, but that one luckily had a bit to switch from SMBus to I2C mode, i.e. no timeout handling: [PATCH v6 1/1] mfd: da9063: Support SMBus and I2C mode signature.asc Description: PGP signature
Re: Errant readings on LM81 with T2080 SoC
On 12/03/21 10:34 am, Guenter Roeck wrote: > On 3/11/21 1:17 PM, Chris Packham wrote: >> On 11/03/21 9:18 pm, Wolfram Sang wrote: Bummer. What is really weird is that you see clock stretching under CPU load. Normally clock stretching is triggered by the device, not by the host. >>> One example: Some hosts need an interrupt per byte to know if they >>> should send ACK or NACK. If that interrupt is delayed, they stretch the >>> clock. >>> >> It feels like something like that is happening. Looking at the T2080 >> Reference manual there is an interesting timing diagram (Figure 14-2 if >> someone feels like looking it up). It shows SCL low between the ACK for >> the address and the data byte. I think if we're delayed in sending the >> next byte we could violate Ttimeout or Tlow:mext from the SMBUS spec. >> > I think that really leaves you only two options that I can see: > Rework the driver to handle critical actions (such as setting TXAK, > and everything else that might result in clock stretching) in the > interrupt handler, or rework the driver to handle everything in > a high priority kernel thread. I've made some reasonable progress on making i2c-mpc more interrupt driven. Assuming it works out for my use-case is there an opinion on making interrupt support mandatory? Looking at all the in-tree dts files that use one of the compatible strings from i2c-mpc.c they all have interrupt properties so in theory nothing is using the polling mode. But there may be some out-of-tree boards or boards using an old dtb that would be affected?
[PATCH] powerpc/mm: Revert "powerpc/mm: Remove DEBUG_VM_PGTABLE support on powerpc"
This reverts commit 675bceb097e6 ("powerpc/mm: Remove DEBUG_VM_PGTABLE support
on powerpc")
All the related issues are fixed by the series
https://lore.kernel.org/linux-mm/20200902114222.181353-1-aneesh.ku...@linux.ibm.com
Hence enable it back
Signed-off-by: Aneesh Kumar K.V
---
Documentation/features/debug/debug-vm-pgtable/arch-support.txt | 2 +-
arch/powerpc/Kconfig | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
index 7aff505af706..fa83403b4aec 100644
--- a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
+++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
@@ -21,7 +21,7 @@
| nios2: | TODO |
|openrisc: | TODO |
| parisc: | TODO |
-| powerpc: | TODO |
+| powerpc: | ok |
| riscv: | ok |
|s390: | ok |
| sh: | TODO |
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 386ae12d8523..982c87d5c051 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -119,6 +119,7 @@ config PPC
#
select ARCH_32BIT_OFF_T if PPC32
select ARCH_HAS_DEBUG_VIRTUAL
+ select ARCH_HAS_DEBUG_VM_PGTABLE
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
--
2.30.2
[PATCH] powerpc/book3s64/kuap: Move Kconfig varriables to BOOK3S_64
With below two commits:
commit c91435d95c49 ("powerpc/book3s64/hash/kuep: Enable KUEP on hash")
commit b2ff33a10c8b ("powerpc/book3s64/hash/kuap: Enable kuap on hash")
the kernel now supports kuap/kuep with hash translation. Hence select the
Kconfig even when radix is disabled.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/platforms/Kconfig.cputype | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index 2e666e569fdf..8e585d8e77ce 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -103,6 +103,8 @@ config PPC_BOOK3S_64
select ARCH_SUPPORTS_NUMA_BALANCING
select IRQ_WORK
select PPC_MM_SLICES
+ select PPC_HAVE_KUEP
+ select PPC_HAVE_KUAP
config PPC_BOOK3E_64
bool "Embedded processors"
@@ -365,8 +367,6 @@ config PPC_RADIX_MMU
bool "Radix MMU Support"
depends on PPC_BOOK3S_64
select ARCH_HAS_GIGANTIC_PAGE
- select PPC_HAVE_KUEP
- select PPC_HAVE_KUAP
default y
help
Enable support for the Power ISA 3.0 Radix style MMU. Currently this
--
2.30.2
Re: Errant readings on LM81 with T2080 SoC
On 3/17/21 8:46 PM, Chris Packham wrote: > > On 12/03/21 10:34 am, Guenter Roeck wrote: >> On 3/11/21 1:17 PM, Chris Packham wrote: >>> On 11/03/21 9:18 pm, Wolfram Sang wrote: > Bummer. What is really weird is that you see clock stretching under > CPU load. Normally clock stretching is triggered by the device, not > by the host. One example: Some hosts need an interrupt per byte to know if they should send ACK or NACK. If that interrupt is delayed, they stretch the clock. >>> It feels like something like that is happening. Looking at the T2080 >>> Reference manual there is an interesting timing diagram (Figure 14-2 if >>> someone feels like looking it up). It shows SCL low between the ACK for >>> the address and the data byte. I think if we're delayed in sending the >>> next byte we could violate Ttimeout or Tlow:mext from the SMBUS spec. >>> >> I think that really leaves you only two options that I can see: >> Rework the driver to handle critical actions (such as setting TXAK, >> and everything else that might result in clock stretching) in the >> interrupt handler, or rework the driver to handle everything in >> a high priority kernel thread. > I've made some reasonable progress on making i2c-mpc more interrupt > driven. Assuming it works out for my use-case is there an opinion on > making interrupt support mandatory? Looking at all the in-tree dts files > that use one of the compatible strings from i2c-mpc.c they all have > interrupt properties so in theory nothing is using the polling mode. But > there may be some out-of-tree boards or boards using an old dtb that > would be affected? > The polling code is from pre-git times. Like 2005 and earlier. I'd say it is about time to get rid of it. Any out-of-tree users had more than 15 years to upstream their code, after all. Guenter
[PATCH 02/10] ARM: disable CONFIG_IDE in footbridge_defconfig
footbridge_defconfig enables CONFIG_IDE but no actual host controller driver, so just drop it. Signed-off-by: Christoph Hellwig --- arch/arm/configs/footbridge_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/configs/footbridge_defconfig b/arch/arm/configs/footbridge_defconfig index 3a7938f244e566..1fe60e0fcf2790 100644 --- a/arch/arm/configs/footbridge_defconfig +++ b/arch/arm/configs/footbridge_defconfig @@ -65,7 +65,6 @@ CONFIG_PARIDE_ON26=m CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y -CONFIG_IDE=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_VENDOR_3COM=y -- 2.30.1
[PATCH 01/10] alpha: use libata instead of the legacy ide driver
Switch the alpha defconfig from the legacy ide driver to libata. Signed-off-by: Christoph Hellwig --- arch/alpha/configs/defconfig | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/alpha/configs/defconfig b/arch/alpha/configs/defconfig index 724c4075df408e..dd2dd9f0861f18 100644 --- a/arch/alpha/configs/defconfig +++ b/arch/alpha/configs/defconfig @@ -25,19 +25,18 @@ CONFIG_PNP=y CONFIG_ISAPNP=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_LOOP=m -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_IDE_GENERIC=y -CONFIG_BLK_DEV_GENERIC=y -CONFIG_BLK_DEV_ALI15X3=y -CONFIG_BLK_DEV_CMD64X=y -CONFIG_BLK_DEV_CY82C693=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=253 # CONFIG_AIC7XXX_DEBUG_ENABLE is not set +CONFIG_ATA=y +# CONFIG_SATA_PMP is not set +CONFIG_PATA_ALI=y +CONFIG_PATA_CMD64X=y +CONFIG_PATA_CYPRESS=y +CONFIG_ATA_GENERIC=y CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_NET_ETHERNET=y -- 2.30.1
remove the legacy ide driver
Hi all, we've been trying to get rid of the legacy ide driver for a while now, and finally scheduled a removal for 2021, which is three month old now. In general distros and most defconfigs have switched to libata long ago, but there are a few exceptions. This series first switches over all remaining defconfigs to use libata and then removes the legacy ide driver. libata mostly covers all hardware supported by the legacy ide driver. There are three mips drivers that are not supported, but the linux-mips list could not identify any users of those. There also are two m68k drivers that do not have libata equivalents, which might or might not have users, so we'll need some input and possibly help from the m68k community here.
[PATCH 03/10] ARM: disable CONFIG_IDE in pxa_defconfig
pxa_defconfig already enables libata including the pata_pcmcia driver, so drop the legacy ide driver and idecs host driver. Signed-off-by: Christoph Hellwig --- arch/arm/configs/pxa_defconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig index bd7dd81c9c5441..c82b8a1d6e84f6 100644 --- a/arch/arm/configs/pxa_defconfig +++ b/arch/arm/configs/pxa_defconfig @@ -215,8 +215,6 @@ CONFIG_IIO=m CONFIG_AD5446=m CONFIG_EEPROM_AT24=m CONFIG_SENSORS_LIS3_SPI=m -CONFIG_IDE=m -CONFIG_BLK_DEV_IDECS=m CONFIG_SCSI=y CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m -- 2.30.1
[PATCH 05/10] MIPS: switch workpad_defconfig from legacy IDE to libata
Use libata instead of the deprecated legacy ide driver in workpad_defconfig. Signed-off-by: Christoph Hellwig --- arch/mips/configs/workpad_defconfig | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/mips/configs/workpad_defconfig b/arch/mips/configs/workpad_defconfig index 891a5f77305da1..4798dc86c9ceaf 100644 --- a/arch/mips/configs/workpad_defconfig +++ b/arch/mips/configs/workpad_defconfig @@ -26,9 +26,12 @@ CONFIG_IP_MULTICAST=y # CONFIG_IPV6 is not set CONFIG_NETWORK_SECMARK=y CONFIG_BLK_DEV_RAM=m -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECS=m -CONFIG_IDE_GENERIC=y +# CONFIG_SCSI_PROC_FS is not set +# CONFIG_SCSI_LOWLEVEL is not set +CONFIG_ATA=y +# CONFIG_ATA_VERBOSE_ERROR is not set +# CONFIG_ATA_FORCE is not set +# CONFIG_ATA_BMDMA is not set CONFIG_NETDEVICES=y CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_3C589=m -- 2.30.1
[PATCH 04/10] MIPS: disable CONFIG_IDE in sb1250_swarm_defconfig
sb1250_swarm_defconfig enables CONFIG_IDE but no actual host controller driver, so just drop CONFIG_IDE, CONFIG_BLK_DEV_IDECD and CONFIG_BLK_DEV_IDETAPE as they are useless. Signed-off-by: Christoph Hellwig --- arch/mips/configs/sb1250_swarm_defconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/mips/configs/sb1250_swarm_defconfig b/arch/mips/configs/sb1250_swarm_defconfig index bb0b1b22ebe164..96a94ebf05bf08 100644 --- a/arch/mips/configs/sb1250_swarm_defconfig +++ b/arch/mips/configs/sb1250_swarm_defconfig @@ -49,9 +49,6 @@ CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=9220 CONFIG_CDROM_PKTCDVD=m CONFIG_ATA_OVER_ETH=m -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_IDETAPE=y CONFIG_RAID_ATTRS=m CONFIG_NETDEVICES=y CONFIG_MACVLAN=m -- 2.30.1
[PATCH 08/10] MIPS: disable CONFIG_IDE in malta*_defconfig
Various malta defconfigs enable CONFIG_IDE for the tc86c001 ide driver, hich is a Toshiba plug in card that does not make much sense to use on bigsur platforms. For all other ATA cards libata support is already enabled. Signed-off-by: Christoph Hellwig --- arch/mips/configs/malta_kvm_defconfig | 3 --- arch/mips/configs/malta_kvm_guest_defconfig | 3 --- arch/mips/configs/maltaup_xpa_defconfig | 3 --- 3 files changed, 9 deletions(-) diff --git a/arch/mips/configs/malta_kvm_defconfig b/arch/mips/configs/malta_kvm_defconfig index 62b1969b4f55b9..b4f9f3d4bd5d34 100644 --- a/arch/mips/configs/malta_kvm_defconfig +++ b/arch/mips/configs/malta_kvm_defconfig @@ -239,9 +239,6 @@ CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_CDROM_PKTCDVD=m CONFIG_ATA_OVER_ETH=m -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_TC86C001=m CONFIG_RAID_ATTRS=m CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m diff --git a/arch/mips/configs/malta_kvm_guest_defconfig b/arch/mips/configs/malta_kvm_guest_defconfig index 9185e0a0aa4551..4d415145d1163e 100644 --- a/arch/mips/configs/malta_kvm_guest_defconfig +++ b/arch/mips/configs/malta_kvm_guest_defconfig @@ -237,9 +237,6 @@ CONFIG_BLK_DEV_RAM=y CONFIG_CDROM_PKTCDVD=m CONFIG_ATA_OVER_ETH=m CONFIG_VIRTIO_BLK=y -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_TC86C001=m CONFIG_RAID_ATTRS=m CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m diff --git a/arch/mips/configs/maltaup_xpa_defconfig b/arch/mips/configs/maltaup_xpa_defconfig index 636311d67a533c..cd536086dca4a4 100644 --- a/arch/mips/configs/maltaup_xpa_defconfig +++ b/arch/mips/configs/maltaup_xpa_defconfig @@ -237,9 +237,6 @@ CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_CDROM_PKTCDVD=m CONFIG_ATA_OVER_ETH=m -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_TC86C001=m CONFIG_RAID_ATTRS=m CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m -- 2.30.1
[PATCH 07/10] MIPS: disable CONFIG_IDE in bigsur_defconfig
bigsur_defconfig enables CONFIG_IDE for the tc86c001 ide driver, which is a Toshiba plug in card that does not make much sense to use on bigsur platforms. For all other ATA cards libata support is already enabled. Signed-off-by: Christoph Hellwig --- arch/mips/configs/bigsur_defconfig | 4 1 file changed, 4 deletions(-) diff --git a/arch/mips/configs/bigsur_defconfig b/arch/mips/configs/bigsur_defconfig index eea9b613bb7402..d83e7d600b0a56 100644 --- a/arch/mips/configs/bigsur_defconfig +++ b/arch/mips/configs/bigsur_defconfig @@ -105,10 +105,6 @@ CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_EEPROM_LEGACY=y CONFIG_EEPROM_MAX6875=y -CONFIG_IDE=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_IDETAPE=y -CONFIG_BLK_DEV_TC86C001=m CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y -- 2.30.1
[PATCH 06/10] MIPS: disable CONFIG_IDE in rbtx49xx_defconfig
rbtx49xx_defconfig enables CONFIG_IDE for the tx4938 and tx4939 ide drivers, but those aren't actually used by the last known remaining user: https://lore.kernel.org/lkml/20210107.101729.1936921832901251107.an...@mba.ocn.ne.jp/ Signed-off-by: Christoph Hellwig --- arch/mips/configs/rbtx49xx_defconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/mips/configs/rbtx49xx_defconfig b/arch/mips/configs/rbtx49xx_defconfig index 5e389db35fa746..69f2300107f961 100644 --- a/arch/mips/configs/rbtx49xx_defconfig +++ b/arch/mips/configs/rbtx49xx_defconfig @@ -44,9 +44,6 @@ CONFIG_MTD_NAND_TXX9NDFMC=m CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=8192 -CONFIG_IDE=y -CONFIG_BLK_DEV_IDE_TX4938=y -CONFIG_BLK_DEV_IDE_TX4939=y CONFIG_NETDEVICES=y CONFIG_NE2000=y CONFIG_SMC91X=y -- 2.30.1
[PATCH 09/10] m68k: use libata instead of the legacy ide driver
Switch the m68 defconfigs from the deprecated ide subsystem to use libata instead. The gayle and buddha and falcon drivers are enabled for libata, while support for the q40 and macide drivers is lost. Signed-off-by: Christoph Hellwig --- arch/m68k/configs/amiga_defconfig | 10 +- arch/m68k/configs/atari_defconfig | 8 arch/m68k/configs/mac_defconfig | 5 - arch/m68k/configs/multi_defconfig | 15 ++- arch/m68k/configs/q40_defconfig | 4 5 files changed, 15 insertions(+), 27 deletions(-) diff --git a/arch/m68k/configs/amiga_defconfig b/arch/m68k/configs/amiga_defconfig index 786656090c5029..fba7275de0fb5f 100644 --- a/arch/m68k/configs/amiga_defconfig +++ b/arch/m68k/configs/amiga_defconfig @@ -323,11 +323,6 @@ CONFIG_BLK_DEV_RAM=y CONFIG_CDROM_PKTCDVD=m CONFIG_ATA_OVER_ETH=m CONFIG_DUMMY_IRQ=m -CONFIG_IDE=y -CONFIG_IDE_GD_ATAPI=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_GAYLE=y -CONFIG_BLK_DEV_BUDDHA=y CONFIG_RAID_ATTRS=m CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y @@ -344,6 +339,11 @@ CONFIG_GVP11_SCSI=y CONFIG_SCSI_A4000T=y CONFIG_SCSI_ZORRO7XX=y CONFIG_SCSI_ZORRO_ESP=y +CONFIG_ATA=y +# CONFIG_ATA_VERBOSE_ERROR is not set +# CONFIG_ATA_BMDMA is not set +CONFIG_PATA_GAYLE=y +CONFIG_PATA_BUDDHA=y CONFIG_MD=y CONFIG_MD_LINEAR=m CONFIG_BLK_DEV_DM=m diff --git a/arch/m68k/configs/atari_defconfig b/arch/m68k/configs/atari_defconfig index 413232626d9d57..235d038be9 100644 --- a/arch/m68k/configs/atari_defconfig +++ b/arch/m68k/configs/atari_defconfig @@ -324,10 +324,6 @@ CONFIG_BLK_DEV_RAM=y CONFIG_CDROM_PKTCDVD=m CONFIG_ATA_OVER_ETH=m CONFIG_DUMMY_IRQ=m -CONFIG_IDE=y -CONFIG_IDE_GD_ATAPI=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_FALCON_IDE=y CONFIG_RAID_ATTRS=m CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y @@ -339,6 +335,10 @@ CONFIG_SCSI_SAS_ATTRS=m CONFIG_ISCSI_TCP=m CONFIG_ISCSI_BOOT_SYSFS=m CONFIG_ATARI_SCSI=y +CONFIG_ATA=y +# CONFIG_ATA_VERBOSE_ERROR is not set +# CONFIG_ATA_BMDMA is not set +CONFIG_PATA_FALCON=y CONFIG_MD=y CONFIG_MD_LINEAR=m CONFIG_BLK_DEV_DM=m diff --git a/arch/m68k/configs/mac_defconfig b/arch/m68k/configs/mac_defconfig index bf15e6c1c939bb..cc92cc4601cb1f 100644 --- a/arch/m68k/configs/mac_defconfig +++ b/arch/m68k/configs/mac_defconfig @@ -315,11 +315,6 @@ CONFIG_BLK_DEV_RAM=y CONFIG_CDROM_PKTCDVD=m CONFIG_ATA_OVER_ETH=m CONFIG_DUMMY_IRQ=m -CONFIG_IDE=y -CONFIG_IDE_GD_ATAPI=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_PLATFORM=y -CONFIG_BLK_DEV_MAC_IDE=y CONFIG_RAID_ATTRS=m CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y diff --git a/arch/m68k/configs/multi_defconfig b/arch/m68k/configs/multi_defconfig index 5466d48fcd9d51..9be9f2ad4ddb84 100644 --- a/arch/m68k/configs/multi_defconfig +++ b/arch/m68k/configs/multi_defconfig @@ -344,15 +344,6 @@ CONFIG_BLK_DEV_RAM=y CONFIG_CDROM_PKTCDVD=m CONFIG_ATA_OVER_ETH=m CONFIG_DUMMY_IRQ=m -CONFIG_IDE=y -CONFIG_IDE_GD_ATAPI=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_PLATFORM=y -CONFIG_BLK_DEV_GAYLE=y -CONFIG_BLK_DEV_BUDDHA=y -CONFIG_BLK_DEV_FALCON_IDE=y -CONFIG_BLK_DEV_MAC_IDE=y -CONFIG_BLK_DEV_Q40IDE=y CONFIG_RAID_ATTRS=m CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y @@ -376,6 +367,12 @@ CONFIG_MVME147_SCSI=y CONFIG_MVME16x_SCSI=y CONFIG_BVME6000_SCSI=y CONFIG_SUN3X_ESP=y +CONFIG_ATA=y +# CONFIG_ATA_VERBOSE_ERROR is not set +# CONFIG_ATA_BMDMA is not set +CONFIG_PATA_FALCON=y +CONFIG_PATA_GAYLE=y +CONFIG_PATA_BUDDHA=y CONFIG_MD=y CONFIG_MD_LINEAR=m CONFIG_BLK_DEV_DM=m diff --git a/arch/m68k/configs/q40_defconfig b/arch/m68k/configs/q40_defconfig index 3ae421cb24a439..ac35e448b1c58f 100644 --- a/arch/m68k/configs/q40_defconfig +++ b/arch/m68k/configs/q40_defconfig @@ -314,10 +314,6 @@ CONFIG_BLK_DEV_RAM=y CONFIG_CDROM_PKTCDVD=m CONFIG_ATA_OVER_ETH=m CONFIG_DUMMY_IRQ=m -CONFIG_IDE=y -CONFIG_IDE_GD_ATAPI=y -CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_Q40IDE=y CONFIG_RAID_ATTRS=m CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y -- 2.30.1
Re: [PATCH] powerpc/numa: Fix topology_physical_package_id() on pSeries
Cédric Le Goater writes:
> Initial commit 15863ff3b8da ("powerpc: Make chip-id information
> available to userspace") introduce a cpu_to_chip_id() routine for the
> PowerNV platform using the "ibm,chip-id" property to query the chip id
> of a CPU. But PAPR does not specify such a property and the node id
> query is broken.
>
> Use cpu_to_node() instead which guarantees to have a correct value on
> all platforms, PowerNV an pSeries.
I'm not convinced this is correct on any platforms :)
The node (nid) is just a number made up by Linux, so it's not a
"physical package id".
It might correspond to a "physical package" (whatever that means), on
existing skiboot, but it's not guaranteed.
The PAPR text around associativity and so on is incredibly dense, but I
think one thing that is clear is that firmware is allowed to present to
us whatever boundaries it thinks are most meaningful.
ie. if two things on one "physical package" have a meaningful distance
between them, then they might be presented to us as two nodes.
Having said that, if you look at the documentation in the kernel we
have:
physical_package_id: physical package id of cpu#. Typically
corresponds to a physical socket number, but the actual value
is architecture and platform dependent.
Which is nicely vague.
But then:
core_siblings: internal kernel map of cpu#'s hardware threads
within the same physical_package_id.
Which is not true for us already on bare metal. And is just wrong on
modern CPUs where there's multiple non-siblings in a single
core/chip/package.
So a patch to update the documentation would be good :)
As far as what we should do in our topology code, I think we should use
the chip-id when we have it - ie. on bare metal.
It may not be exactly correct, but it's at least not filtered through
any indirection about NUMA-ness, ie. the associativity properties.
Also we've been using it for several years and I don't think we should
risk breaking anything by changing the value now.
As far as pseries, I'm still a bit dubious, but maybe using nid is
better than providing nothing, even if it is a lie.
cheers
Re: [PATCH] powerpc: arch/powerpc/kernel/setup_64.c - cleanup warnings
在 2021/3/17 19:57, Michael Ellerman 写道:
Daniel Axtens writes:
"heying (H)" writes:
Thank you for your reply.
在 2021/3/17 11:04, Daniel Axtens 写道:
Hi He Ying,
Thank you for this patch.
I'm not sure what the precise rules for Fixes are, but I wonder if this
should have:
Fixes: 9a32a7e78bd0 ("powerpc/64s: flush L1D after user accesses")
Fixes: f79643787e0a ("powerpc/64s: flush L1D on kernel entry")
Is that necessary for warning cleanups? I thought 'Fixes' tags are
needed only for
bugfix patches. Can someone tell me whether I am right?
Yeah, I'm not sure either. Hopefully mpe will let us know.
It's not necessary to add a Fixes tag for a patch like this, but you can
add one if you think it's important that the fix gets backported.
I don't think the cleanups in this case are that important, so I
wouldn't bother with a Fixes tag.
Okay. That's a good explanation to me. Thanks.
[PATCH 1/2] audit: add support for the openat2 syscall
The openat2(2) syscall was added in kernel v5.6 with commit fddb5d430ad9
("open: introduce openat2(2) syscall")
Add the openat2(2) syscall to the audit syscall classifier.
See the github issue
https://github.com/linux-audit/audit-kernel/issues/67
Signed-off-by: Richard Guy Briggs
---
arch/alpha/kernel/audit.c | 2 ++
arch/ia64/kernel/audit.c | 2 ++
arch/parisc/kernel/audit.c | 2 ++
arch/parisc/kernel/compat_audit.c | 2 ++
arch/powerpc/kernel/audit.c| 2 ++
arch/powerpc/kernel/compat_audit.c | 2 ++
arch/s390/kernel/audit.c | 2 ++
arch/s390/kernel/compat_audit.c| 2 ++
arch/sparc/kernel/audit.c | 2 ++
arch/sparc/kernel/compat_audit.c | 2 ++
arch/x86/ia32/audit.c | 2 ++
arch/x86/kernel/audit_64.c | 2 ++
kernel/auditsc.c | 3 +++
lib/audit.c| 4
lib/compat_audit.c | 4
15 files changed, 35 insertions(+)
diff --git a/arch/alpha/kernel/audit.c b/arch/alpha/kernel/audit.c
index 96a9d18ff4c4..06a911b685d1 100644
--- a/arch/alpha/kernel/audit.c
+++ b/arch/alpha/kernel/audit.c
@@ -42,6 +42,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 3;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/ia64/kernel/audit.c b/arch/ia64/kernel/audit.c
index 5192ca899fe6..5eaa888c8fd3 100644
--- a/arch/ia64/kernel/audit.c
+++ b/arch/ia64/kernel/audit.c
@@ -43,6 +43,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 3;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/parisc/kernel/audit.c b/arch/parisc/kernel/audit.c
index 9eb47b2225d2..fc721a7727ba 100644
--- a/arch/parisc/kernel/audit.c
+++ b/arch/parisc/kernel/audit.c
@@ -52,6 +52,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 3;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/parisc/kernel/compat_audit.c
b/arch/parisc/kernel/compat_audit.c
index 20c39c9d86a9..fc6d35918c44 100644
--- a/arch/parisc/kernel/compat_audit.c
+++ b/arch/parisc/kernel/compat_audit.c
@@ -35,6 +35,8 @@ int parisc32_classify_syscall(unsigned syscall)
return 3;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/powerpc/kernel/audit.c b/arch/powerpc/kernel/audit.c
index a27f3d09..8f32700b0baa 100644
--- a/arch/powerpc/kernel/audit.c
+++ b/arch/powerpc/kernel/audit.c
@@ -54,6 +54,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/powerpc/kernel/compat_audit.c
b/arch/powerpc/kernel/compat_audit.c
index 55c6ccda0a85..ebe45534b1c9 100644
--- a/arch/powerpc/kernel/compat_audit.c
+++ b/arch/powerpc/kernel/compat_audit.c
@@ -38,6 +38,8 @@ int ppc32_classify_syscall(unsigned syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/s390/kernel/audit.c b/arch/s390/kernel/audit.c
index d395c6c9944c..d964cb94cfaf 100644
--- a/arch/s390/kernel/audit.c
+++ b/arch/s390/kernel/audit.c
@@ -54,6 +54,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/s390/kernel/compat_audit.c b/arch/s390/kernel/compat_audit.c
index 444fb1f66944..f7b32933ce0e 100644
--- a/arch/s390/kernel/compat_audit.c
+++ b/arch/s390/kernel/compat_audit.c
@@ -39,6 +39,8 @@ int s390_classify_syscall(unsigned syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/sparc/kernel/audit.c b/arch/sparc/kernel/audit.c
index a6e91bf34d48..b6dcca9c6520 100644
--- a/arch/sparc/kernel/audit.c
+++ b/arch/sparc/kernel/audit.c
@@ -55,6 +55,8 @@ int audit_classify_syscall(int abi, unsigned int syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/sparc/kernel/compat_audit.c b/arch/sparc/kernel/compat_audit.c
index
Re: [PATCH -next] powerpc: kernel/time.c - cleanup warnings
在 2021/3/17 19:16, Christophe Leroy 写道:
Le 17/03/2021 à 11:34, He Ying a écrit :
We found these warnings in arch/powerpc/kernel/time.c as follows:
warning: symbol 'decrementer_max' was not declared. Should it be static?
warning: symbol 'rtc_lock' was not declared. Should it be static?
warning: symbol 'dtl_consumer' was not declared. Should it be static?
Declare 'decrementer_max' in arch/powerpc/include/asm/time.h. And
include
proper header in which 'rtc_lock' is declared. Move 'dtl_consumer'
definition behind "include " because 'dtl_consumer' is
declared
there.
Reported-by: Hulk Robot
Signed-off-by: He Ying
---
arch/powerpc/include/asm/time.h | 1 +
arch/powerpc/kernel/time.c | 7 +++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/time.h
b/arch/powerpc/include/asm/time.h
index 8dd3cdb25338..2cd2b50bedda 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -22,6 +22,7 @@ extern unsigned long tb_ticks_per_jiffy;
extern unsigned long tb_ticks_per_usec;
extern unsigned long tb_ticks_per_sec;
extern struct clock_event_device decrementer_clockevent;
+extern u64 decrementer_max;
extern void generic_calibrate_decr(void);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index b67d93a609a2..409967713ca6 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
I don't think that's the good place. It has no link to powerpc, it is
only by chance that it has the same name.
As rtc_lock is defined in powerpc time.c, I think you should declare
it in powerpc asm/time.h
My first thought was the same as yours. I tried to add declaration in
powerpc asm/time.h, but got a compiling error:
drivers/rtc/rtc-vr41xx.c:75:24: error: static declaration of ‘rtc_lock’
follows non-static declaration
static DEFINE_SPINLOCK(rtc_lock);
In file included from ./arch/powerpc/include/asm/delay.h:7:0,
from ./arch/powerpc/include/asm/io.h:33,
from ./include/linux/io.h:13,
from drivers/rtc/rtc-vr41xx.c:11:
./arch/powerpc/include/asm/time.h:25:19: note: previous declaration of
‘rtc_lock’ was here
extern spinlock_t rtc_lock;
There's a conflict. Perhaps I can rename it in drivers/rtc/rtc-vr41xx.c.
But I find an existing declaration in linux/mc146818rtc.h and there's
only one definition for 'rtc_lock' in powerpc.
There's some includes of mc146818rtc.h in powperc. I wonder they point
to the same thing. But I'm not very sure
because the header's name looks a bit strange.
#include
#include
@@ -150,10 +151,6 @@ bool tb_invalid;
u64 __cputime_usec_factor;
EXPORT_SYMBOL(__cputime_usec_factor);
-#ifdef CONFIG_PPC_SPLPAR
-void (*dtl_consumer)(struct dtl_entry *, u64);
-#endif
-
static void calc_cputime_factors(void)
{
struct div_result res;
@@ -179,6 +176,8 @@ static inline unsigned long read_spurr(unsigned
long tb)
#include
+void (*dtl_consumer)(struct dtl_entry *, u64);
+
/*
* Scan the dispatch trace log and count up the stolen time.
* Should be called with interrupts disabled.
.
Re: [PATCH v9 3/8] powerpc/kprobes: Mark newly allocated probes as RO
On Wed, Mar 17, 2021 at 5:12 PM Christophe Leroy wrote: > > > > Le 16/03/2021 à 04:17, Jordan Niethe a écrit : > > From: Russell Currey > > > > With CONFIG_STRICT_KERNEL_RWX=y and CONFIG_KPROBES=y, there will be one > > W+X page at boot by default. This can be tested with > > CONFIG_PPC_PTDUMP=y and CONFIG_PPC_DEBUG_WX=y set, and checking the > > kernel log during boot. > > > > Add an arch specific insn page allocator which returns RO pages if > > STRICT_KERNEL_RWX is enabled. This page is only written to with > > patch_instruction() which is able to write RO pages. > > > > Did you investigate BPF ? The problematic looks more or less similar to > kprobe: > > bpf_jit_compile() in arch/powerpc/net/bpf_jit_comp.c calls module_alloc(), > which provides it with > PAGE_KERNEL_TEXT memory, ie RWX. That function is only used on PPC32 which > still has Classic BPF, > and this is about to go away with future series > https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1608112796.git.christophe.le...@csgroup.eu/ > > PPC64 has Extended BPF instead, and PPC32 will it the future too. > bpf_int_jit_compile() in arch/powerpc/net/bpf_jit_comp64.c calls > bpf_jit_binary_alloc() which uses > bpf_jit_alloc_exec(). > > bpf_jit_alloc_exec() is a weak function that should be redefined for powerpc > I think, more or less > like alloc_insn_page() for kprobes. Thanks, that is a good point. I will handle bpf with the next revision. > > Christophe
