* [PATCH v3 06/17] riscv: drop unneeded node initialization
From: Mike Rapoport @ 2020-08-18 15:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Thomas Gleixner, Emil Renner Berthing, linux-sh, Peter Zijlstra,
Dave Hansen, linux-mips, Max Filippov, Paul Mackerras, sparclinux,
linux-riscv, Will Deacon, Christoph Hellwig, Marek Szyprowski,
linux-arch, linux-s390, linux-c6x-dev, Baoquan He, x86,
Russell King, Mike Rapoport, clang-built-linux, Ingo Molnar,
linux-arm-kernel, Catalin Marinas, uclinux-h8-devel, linux-xtensa,
openrisc, Borislav Petkov, Andy Lutomirski, Paul Walmsley,
Stafford Horne, Hari Bathini, Daniel Axtens, Michal Simek,
Yoshinori Sato, linux-mm, linux-kernel, iommu, Palmer Dabbelt,
linuxppc-dev, Mike Rapoport
In-Reply-To: <20200818151634.14343-1-rppt@kernel.org>
From: Mike Rapoport <rppt@linux.ibm.com>
RISC-V does not (yet) support NUMA and for UMA architectures node 0 is
used implicitly during early memory initialization.
There is no need to call memblock_set_node(), remove this call and the
surrounding code.
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
arch/riscv/mm/init.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 787c75f751a5..0485cfaacc72 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -191,15 +191,6 @@ void __init setup_bootmem(void)
early_init_fdt_scan_reserved_mem();
memblock_allow_resize();
memblock_dump_all();
-
- for_each_memblock(memory, reg) {
- unsigned long start_pfn = memblock_region_memory_base_pfn(reg);
- unsigned long end_pfn = memblock_region_memory_end_pfn(reg);
-
- memblock_set_node(PFN_PHYS(start_pfn),
- PFN_PHYS(end_pfn - start_pfn),
- &memblock.memory, 0);
- }
}
#ifdef CONFIG_MMU
--
2.26.2
^ permalink raw reply related
* [PATCH v3 05/17] h8300, nds32, openrisc: simplify detection of memory extents
From: Mike Rapoport @ 2020-08-18 15:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Thomas Gleixner, Emil Renner Berthing, linux-sh, Peter Zijlstra,
Dave Hansen, linux-mips, Max Filippov, Paul Mackerras, sparclinux,
linux-riscv, Will Deacon, Christoph Hellwig, Marek Szyprowski,
linux-arch, linux-s390, linux-c6x-dev, Baoquan He, x86,
Russell King, Mike Rapoport, clang-built-linux, Ingo Molnar,
linux-arm-kernel, Catalin Marinas, uclinux-h8-devel, linux-xtensa,
openrisc, Borislav Petkov, Andy Lutomirski, Paul Walmsley,
Stafford Horne, Hari Bathini, Daniel Axtens, Michal Simek,
Yoshinori Sato, linux-mm, linux-kernel, iommu, Palmer Dabbelt,
linuxppc-dev, Mike Rapoport
In-Reply-To: <20200818151634.14343-1-rppt@kernel.org>
From: Mike Rapoport <rppt@linux.ibm.com>
Instead of traversing memblock.memory regions to find memory_start and
memory_end, simply query memblock_{start,end}_of_DRAM().
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Stafford Horne <shorne@gmail.com>
---
arch/h8300/kernel/setup.c | 8 +++-----
arch/nds32/kernel/setup.c | 8 ++------
arch/openrisc/kernel/setup.c | 9 ++-------
3 files changed, 7 insertions(+), 18 deletions(-)
diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c
index 28ac88358a89..0281f92eea3d 100644
--- a/arch/h8300/kernel/setup.c
+++ b/arch/h8300/kernel/setup.c
@@ -74,17 +74,15 @@ static void __init bootmem_init(void)
memory_end = memory_start = 0;
/* Find main memory where is the kernel */
- for_each_memblock(memory, region) {
- memory_start = region->base;
- memory_end = region->base + region->size;
- }
+ memory_start = memblock_start_of_DRAM();
+ memory_end = memblock_end_of_DRAM();
if (!memory_end)
panic("No memory!");
/* setup bootmem globals (we use no_bootmem, but mm still depends on this) */
min_low_pfn = PFN_UP(memory_start);
- max_low_pfn = PFN_DOWN(memblock_end_of_DRAM());
+ max_low_pfn = PFN_DOWN(memory_end);
max_pfn = max_low_pfn;
memblock_reserve(__pa(_stext), _end - _stext);
diff --git a/arch/nds32/kernel/setup.c b/arch/nds32/kernel/setup.c
index a066efbe53c0..c356e484dcab 100644
--- a/arch/nds32/kernel/setup.c
+++ b/arch/nds32/kernel/setup.c
@@ -249,12 +249,8 @@ static void __init setup_memory(void)
memory_end = memory_start = 0;
/* Find main memory where is the kernel */
- for_each_memblock(memory, region) {
- memory_start = region->base;
- memory_end = region->base + region->size;
- pr_info("%s: Memory: 0x%x-0x%x\n", __func__,
- memory_start, memory_end);
- }
+ memory_start = memblock_start_of_DRAM();
+ memory_end = memblock_end_of_DRAM();
if (!memory_end) {
panic("No memory!");
diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
index b18e775f8be3..5a5940f7ebb1 100644
--- a/arch/openrisc/kernel/setup.c
+++ b/arch/openrisc/kernel/setup.c
@@ -48,17 +48,12 @@ static void __init setup_memory(void)
unsigned long ram_start_pfn;
unsigned long ram_end_pfn;
phys_addr_t memory_start, memory_end;
- struct memblock_region *region;
memory_end = memory_start = 0;
/* Find main memory where is the kernel, we assume its the only one */
- for_each_memblock(memory, region) {
- memory_start = region->base;
- memory_end = region->base + region->size;
- printk(KERN_INFO "%s: Memory: 0x%x-0x%x\n", __func__,
- memory_start, memory_end);
- }
+ memory_start = memblock_start_of_DRAM();
+ memory_end = memblock_end_of_DRAM();
if (!memory_end) {
panic("No memory!");
--
2.26.2
^ permalink raw reply related
* [PATCH v3 04/17] arm64: numa: simplify dummy_numa_init()
From: Mike Rapoport @ 2020-08-18 15:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Thomas Gleixner, Emil Renner Berthing, linux-sh, Peter Zijlstra,
Dave Hansen, linux-mips, Max Filippov, Paul Mackerras, sparclinux,
linux-riscv, Will Deacon, Christoph Hellwig, Marek Szyprowski,
linux-arch, linux-s390, linux-c6x-dev, Baoquan He, x86,
Russell King, Mike Rapoport, clang-built-linux, Ingo Molnar,
linux-arm-kernel, Catalin Marinas, uclinux-h8-devel, linux-xtensa,
openrisc, Borislav Petkov, Andy Lutomirski, Paul Walmsley,
Stafford Horne, Hari Bathini, Daniel Axtens, Michal Simek,
Yoshinori Sato, linux-mm, linux-kernel, iommu, Palmer Dabbelt,
Jonathan Cameron, linuxppc-dev, Mike Rapoport
In-Reply-To: <20200818151634.14343-1-rppt@kernel.org>
From: Mike Rapoport <rppt@linux.ibm.com>
dummy_numa_init() loops over memblock.memory and passes nid=0 to
numa_add_memblk() which essentially wraps memblock_set_node(). However,
memblock_set_node() can cope with entire memory span itself, so the loop
over memblock.memory regions is redundant.
Using a single call to memblock_set_node() rather than a loop also fixes an
issue with a buggy ACPI firmware in which the SRAT table covers some but
not all of the memory in the EFI memory map.
Jonathan Cameron says:
This issue can be easily triggered by having an SRAT table which fails
to cover all elements of the EFI memory map.
This firmware error is detected and a warning printed. e.g.
"NUMA: Warning: invalid memblk node 64 [mem 0x240000000-0x27fffffff]"
At that point we fall back to dummy_numa_init().
However, the failed ACPI init has left us with our memblocks all broken
up as we split them when trying to assign them to NUMA nodes.
We then iterate over the memblocks and add them to node 0.
numa_add_memblk() calls memblock_set_node() which merges regions that
were previously split up during the earlier attempt to add them to different
nodes during parsing of SRAT.
This means elements are moved in the memblock array and we can end up
in a different memblock after the call to numa_add_memblk().
Result is:
Unable to handle kernel paging request at virtual address 0000000000003a40
Mem abort info:
ESR = 0x96000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
[0000000000003a40] user address but active_mm is swapper
Internal error: Oops: 96000004 [#1] PREEMPT SMP
...
Call trace:
sparse_init_nid+0x5c/0x2b0
sparse_init+0x138/0x170
bootmem_init+0x80/0xe0
setup_arch+0x2a0/0x5fc
start_kernel+0x8c/0x648
Replace the loop with a single call to memblock_set_node() to the entire
memory.
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/mm/numa.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 73f8b49d485c..8a97cd3d2dfe 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -423,19 +423,16 @@ static int __init numa_init(int (*init_func)(void))
*/
static int __init dummy_numa_init(void)
{
+ phys_addr_t start = memblock_start_of_DRAM();
+ phys_addr_t end = memblock_end_of_DRAM();
int ret;
- struct memblock_region *mblk;
if (numa_off)
pr_info("NUMA disabled\n"); /* Forced off on command line. */
- pr_info("Faking a node at [mem %#018Lx-%#018Lx]\n",
- memblock_start_of_DRAM(), memblock_end_of_DRAM() - 1);
-
- for_each_memblock(memory, mblk) {
- ret = numa_add_memblk(0, mblk->base, mblk->base + mblk->size);
- if (!ret)
- continue;
+ pr_info("Faking a node at [mem %#018Lx-%#018Lx]\n", start, end - 1);
+ ret = numa_add_memblk(0, start, end);
+ if (ret) {
pr_err("NUMA init failed\n");
return ret;
}
--
2.26.2
^ permalink raw reply related
* [PATCH v3 03/17] arm, xtensa: simplify initialization of high memory pages
From: Mike Rapoport @ 2020-08-18 15:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Thomas Gleixner, Emil Renner Berthing, linux-sh, Peter Zijlstra,
Dave Hansen, linux-mips, Max Filippov, Paul Mackerras, sparclinux,
linux-riscv, Will Deacon, Christoph Hellwig, Marek Szyprowski,
linux-arch, linux-s390, linux-c6x-dev, Baoquan He, x86,
Russell King, Mike Rapoport, clang-built-linux, Ingo Molnar,
linux-arm-kernel, Catalin Marinas, uclinux-h8-devel, linux-xtensa,
openrisc, Borislav Petkov, Andy Lutomirski, Paul Walmsley,
Stafford Horne, Hari Bathini, Daniel Axtens, Michal Simek,
Yoshinori Sato, linux-mm, linux-kernel, iommu, Palmer Dabbelt,
linuxppc-dev, Mike Rapoport
In-Reply-To: <20200818151634.14343-1-rppt@kernel.org>
From: Mike Rapoport <rppt@linux.ibm.com>
The function free_highpages() in both arm and xtensa essentially open-code
for_each_free_mem_range() loop to detect high memory pages that were not
reserved and that should be initialized and passed to the buddy allocator.
Replace open-coded implementation of for_each_free_mem_range() with usage
of memblock API to simplify the code.
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Max Filippov <jcmvbkbc@gmail.com> # xtensa
Tested-by: Max Filippov <jcmvbkbc@gmail.com> # xtensa
---
arch/arm/mm/init.c | 48 +++++++------------------------------
arch/xtensa/mm/init.c | 55 ++++++++-----------------------------------
2 files changed, 18 insertions(+), 85 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 000c1b48e973..50a5a30a78ff 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -347,61 +347,29 @@ static void __init free_unused_memmap(void)
#endif
}
-#ifdef CONFIG_HIGHMEM
-static inline void free_area_high(unsigned long pfn, unsigned long end)
-{
- for (; pfn < end; pfn++)
- free_highmem_page(pfn_to_page(pfn));
-}
-#endif
-
static void __init free_highpages(void)
{
#ifdef CONFIG_HIGHMEM
unsigned long max_low = max_low_pfn;
- struct memblock_region *mem, *res;
+ phys_addr_t range_start, range_end;
+ u64 i;
/* set highmem page free */
- for_each_memblock(memory, mem) {
- unsigned long start = memblock_region_memory_base_pfn(mem);
- unsigned long end = memblock_region_memory_end_pfn(mem);
+ for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
+ &range_start, &range_end, NULL) {
+ unsigned long start = PHYS_PFN(range_start);
+ unsigned long end = PHYS_PFN(range_end);
/* Ignore complete lowmem entries */
if (end <= max_low)
continue;
- if (memblock_is_nomap(mem))
- continue;
-
/* Truncate partial highmem entries */
if (start < max_low)
start = max_low;
- /* Find and exclude any reserved regions */
- for_each_memblock(reserved, res) {
- unsigned long res_start, res_end;
-
- res_start = memblock_region_reserved_base_pfn(res);
- res_end = memblock_region_reserved_end_pfn(res);
-
- if (res_end < start)
- continue;
- if (res_start < start)
- res_start = start;
- if (res_start > end)
- res_start = end;
- if (res_end > end)
- res_end = end;
- if (res_start != start)
- free_area_high(start, res_start);
- start = res_end;
- if (start == end)
- break;
- }
-
- /* And now free anything which remains */
- if (start < end)
- free_area_high(start, end);
+ for (; start < end; start++)
+ free_highmem_page(pfn_to_page(start));
}
#endif
}
diff --git a/arch/xtensa/mm/init.c b/arch/xtensa/mm/init.c
index a05b306cf371..ad9d59d93f39 100644
--- a/arch/xtensa/mm/init.c
+++ b/arch/xtensa/mm/init.c
@@ -79,67 +79,32 @@ void __init zones_init(void)
free_area_init(max_zone_pfn);
}
-#ifdef CONFIG_HIGHMEM
-static void __init free_area_high(unsigned long pfn, unsigned long end)
-{
- for (; pfn < end; pfn++)
- free_highmem_page(pfn_to_page(pfn));
-}
-
static void __init free_highpages(void)
{
+#ifdef CONFIG_HIGHMEM
unsigned long max_low = max_low_pfn;
- struct memblock_region *mem, *res;
+ phys_addr_t range_start, range_end;
+ u64 i;
- reset_all_zones_managed_pages();
/* set highmem page free */
- for_each_memblock(memory, mem) {
- unsigned long start = memblock_region_memory_base_pfn(mem);
- unsigned long end = memblock_region_memory_end_pfn(mem);
+ for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
+ &range_start, &range_end, NULL) {
+ unsigned long start = PHYS_PFN(range_start);
+ unsigned long end = PHYS_PFN(range_end);
/* Ignore complete lowmem entries */
if (end <= max_low)
continue;
- if (memblock_is_nomap(mem))
- continue;
-
/* Truncate partial highmem entries */
if (start < max_low)
start = max_low;
- /* Find and exclude any reserved regions */
- for_each_memblock(reserved, res) {
- unsigned long res_start, res_end;
-
- res_start = memblock_region_reserved_base_pfn(res);
- res_end = memblock_region_reserved_end_pfn(res);
-
- if (res_end < start)
- continue;
- if (res_start < start)
- res_start = start;
- if (res_start > end)
- res_start = end;
- if (res_end > end)
- res_end = end;
- if (res_start != start)
- free_area_high(start, res_start);
- start = res_end;
- if (start == end)
- break;
- }
-
- /* And now free anything which remains */
- if (start < end)
- free_area_high(start, end);
+ for (; start < end; start++)
+ free_highmem_page(pfn_to_page(start));
}
-}
-#else
-static void __init free_highpages(void)
-{
-}
#endif
+}
/*
* Initialize memory pages.
--
2.26.2
^ permalink raw reply related
* [PATCH v3 02/17] dma-contiguous: simplify cma_early_percent_memory()
From: Mike Rapoport @ 2020-08-18 15:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Thomas Gleixner, Emil Renner Berthing, linux-sh, Peter Zijlstra,
Dave Hansen, linux-mips, Max Filippov, Paul Mackerras, sparclinux,
linux-riscv, Will Deacon, Christoph Hellwig, Marek Szyprowski,
linux-arch, linux-s390, linux-c6x-dev, Baoquan He, x86,
Russell King, Mike Rapoport, clang-built-linux, Ingo Molnar,
linux-arm-kernel, Catalin Marinas, uclinux-h8-devel, linux-xtensa,
openrisc, Borislav Petkov, Andy Lutomirski, Paul Walmsley,
Stafford Horne, Hari Bathini, Daniel Axtens, Michal Simek,
Yoshinori Sato, linux-mm, linux-kernel, iommu, Palmer Dabbelt,
linuxppc-dev, Mike Rapoport
In-Reply-To: <20200818151634.14343-1-rppt@kernel.org>
From: Mike Rapoport <rppt@linux.ibm.com>
The memory size calculation in cma_early_percent_memory() traverses
memblock.memory rather than simply call memblock_phys_mem_size(). The
comment in that function suggests that at some point there should have been
call to memblock_analyze() before memblock_phys_mem_size() could be used.
As of now, there is no memblock_analyze() at all and
memblock_phys_mem_size() can be used as soon as cold-plug memory is
registerd with memblock.
Replace loop over memblock.memory with a call to memblock_phys_mem_size().
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Baoquan He <bhe@redhat.com>
---
kernel/dma/contiguous.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index cff7e60968b9..0369fd5fda8f 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -73,16 +73,7 @@ early_param("cma", early_cma);
static phys_addr_t __init __maybe_unused cma_early_percent_memory(void)
{
- struct memblock_region *reg;
- unsigned long total_pages = 0;
-
- /*
- * We cannot use memblock_phys_mem_size() here, because
- * memblock_analyze() has not been called yet.
- */
- for_each_memblock(memory, reg)
- total_pages += memblock_region_memory_end_pfn(reg) -
- memblock_region_memory_base_pfn(reg);
+ unsigned long total_pages = PHYS_PFN(memblock_phys_mem_size());
return (total_pages * CONFIG_CMA_SIZE_PERCENTAGE / 100) << PAGE_SHIFT;
}
--
2.26.2
^ permalink raw reply related
* [PATCH v3 01/17] KVM: PPC: Book3S HV: simplify kvm_cma_reserve()
From: Mike Rapoport @ 2020-08-18 15:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Thomas Gleixner, Emil Renner Berthing, linux-sh, Peter Zijlstra,
Dave Hansen, linux-mips, Max Filippov, Paul Mackerras, sparclinux,
linux-riscv, Will Deacon, Christoph Hellwig, Marek Szyprowski,
linux-arch, linux-s390, linux-c6x-dev, Baoquan He, x86,
Russell King, Mike Rapoport, clang-built-linux, Ingo Molnar,
linux-arm-kernel, Catalin Marinas, uclinux-h8-devel, linux-xtensa,
openrisc, Borislav Petkov, Andy Lutomirski, Paul Walmsley,
Stafford Horne, Hari Bathini, Daniel Axtens, Michal Simek,
Yoshinori Sato, linux-mm, linux-kernel, iommu, Palmer Dabbelt,
linuxppc-dev, Mike Rapoport
In-Reply-To: <20200818151634.14343-1-rppt@kernel.org>
From: Mike Rapoport <rppt@linux.ibm.com>
The memory size calculation in kvm_cma_reserve() traverses memblock.memory
rather than simply call memblock_phys_mem_size(). The comment in that
function suggests that at some point there should have been call to
memblock_analyze() before memblock_phys_mem_size() could be used.
As of now, there is no memblock_analyze() at all and
memblock_phys_mem_size() can be used as soon as cold-plug memory is
registerd with memblock.
Replace loop over memblock.memory with a call to memblock_phys_mem_size().
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
arch/powerpc/kvm/book3s_hv_builtin.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c b/arch/powerpc/kvm/book3s_hv_builtin.c
index 073617ce83e0..8f58dd20b362 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -95,23 +95,15 @@ EXPORT_SYMBOL_GPL(kvm_free_hpt_cma);
void __init kvm_cma_reserve(void)
{
unsigned long align_size;
- struct memblock_region *reg;
- phys_addr_t selected_size = 0;
+ phys_addr_t selected_size;
/*
* We need CMA reservation only when we are in HV mode
*/
if (!cpu_has_feature(CPU_FTR_HVMODE))
return;
- /*
- * We cannot use memblock_phys_mem_size() here, because
- * memblock_analyze() has not been called yet.
- */
- for_each_memblock(memory, reg)
- selected_size += memblock_region_memory_end_pfn(reg) -
- memblock_region_memory_base_pfn(reg);
- selected_size = (selected_size * kvm_cma_resv_ratio / 100) << PAGE_SHIFT;
+ selected_size = PAGE_ALIGN(memblock_phys_mem_size() * kvm_cma_resv_ratio / 100);
if (selected_size) {
pr_info("%s: reserving %ld MiB for global area\n", __func__,
(unsigned long)selected_size / SZ_1M);
--
2.26.2
^ permalink raw reply related
* [PATCH v3 00/17] memblock: seasonal cleaning^w cleanup
From: Mike Rapoport @ 2020-08-18 15:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Thomas Gleixner, Emil Renner Berthing, linux-sh, Peter Zijlstra,
Dave Hansen, linux-mips, Max Filippov, Paul Mackerras, sparclinux,
linux-riscv, Will Deacon, Christoph Hellwig, Marek Szyprowski,
linux-arch, linux-s390, linux-c6x-dev, Baoquan He, x86,
Russell King, Mike Rapoport, clang-built-linux, Ingo Molnar,
linux-arm-kernel, Catalin Marinas, uclinux-h8-devel, linux-xtensa,
openrisc, Borislav Petkov, Andy Lutomirski, Paul Walmsley,
Stafford Horne, Hari Bathini, Daniel Axtens, Michal Simek,
Yoshinori Sato, linux-mm, linux-kernel, iommu, Palmer Dabbelt,
linuxppc-dev, Mike Rapoport
From: Mike Rapoport <rppt@linux.ibm.com>
Hi,
These patches simplify several uses of memblock iterators and hide some of
the memblock implementation details from the rest of the system.
The patches are on top of v5.9-rc1
v3 changes:
* rebase on v5.9-rc1, as the result this required some non-trivial changes
in patches 10 and 16. I didn't add Baoquan's Reviewed-by to theses
patches, but I keept Thomas and Miguel
* Add Acked-by from Thomas and Miguel as there were changes in MIPS and
only trivial changes in .clang-format
* Added Reviewed-by from Baoquan except for the patches 10 and 16
* Fixed misc build errors and warnings reported by kbuild bot
* Updated PowerPC KVM reservation size (patch 2), as per Daniel's comment
v2 changes:
* replace for_each_memblock() with two versions, one for memblock.memory
and another one for memblock.reserved
* fix overzealous cleanup of powerpc fadamp: keep the traversal over the
memblocks, but use better suited iterators
* don't remove traversal over memblock.reserved in x86 numa cleanup but
replace for_each_memblock() with new for_each_reserved_mem_region()
* simplify ramdisk and crash kernel allocations on x86
* drop more redundant and unused code: __next_reserved_mem_region() and
memblock_mem_size()
* add description of numa initialization fix on arm64 (thanks Jonathan)
* add Acked and Reviewed tags
Mike Rapoport (17):
KVM: PPC: Book3S HV: simplify kvm_cma_reserve()
dma-contiguous: simplify cma_early_percent_memory()
arm, xtensa: simplify initialization of high memory pages
arm64: numa: simplify dummy_numa_init()
h8300, nds32, openrisc: simplify detection of memory extents
riscv: drop unneeded node initialization
mircoblaze: drop unneeded NUMA and sparsemem initializations
memblock: make for_each_memblock_type() iterator private
memblock: make memblock_debug and related functionality private
memblock: reduce number of parameters in for_each_mem_range()
arch, mm: replace for_each_memblock() with for_each_mem_pfn_range()
arch, drivers: replace for_each_membock() with for_each_mem_range()
x86/setup: simplify initrd relocation and reservation
x86/setup: simplify reserve_crashkernel()
memblock: remove unused memblock_mem_size()
memblock: implement for_each_reserved_mem_region() using
__next_mem_region()
memblock: use separate iterators for memory and reserved regions
.clang-format | 5 +-
arch/arm/kernel/setup.c | 18 +++--
arch/arm/mm/init.c | 59 +++------------
arch/arm/mm/mmu.c | 39 ++++------
arch/arm/mm/pmsa-v7.c | 23 +++---
arch/arm/mm/pmsa-v8.c | 17 ++---
arch/arm/xen/mm.c | 7 +-
arch/arm64/kernel/machine_kexec_file.c | 6 +-
arch/arm64/kernel/setup.c | 4 +-
arch/arm64/mm/init.c | 11 +--
arch/arm64/mm/kasan_init.c | 10 +--
arch/arm64/mm/mmu.c | 11 +--
arch/arm64/mm/numa.c | 15 ++--
arch/c6x/kernel/setup.c | 9 ++-
arch/h8300/kernel/setup.c | 8 +-
arch/microblaze/mm/init.c | 21 ++----
arch/mips/cavium-octeon/dma-octeon.c | 12 +--
arch/mips/kernel/setup.c | 31 ++++----
arch/mips/netlogic/xlp/setup.c | 2 +-
arch/nds32/kernel/setup.c | 8 +-
arch/openrisc/kernel/setup.c | 9 +--
arch/openrisc/mm/init.c | 8 +-
arch/powerpc/kernel/fadump.c | 57 +++++++-------
arch/powerpc/kexec/file_load_64.c | 16 ++--
arch/powerpc/kvm/book3s_hv_builtin.c | 12 +--
arch/powerpc/mm/book3s64/hash_utils.c | 16 ++--
arch/powerpc/mm/book3s64/radix_pgtable.c | 10 +--
arch/powerpc/mm/kasan/kasan_init_32.c | 8 +-
arch/powerpc/mm/mem.c | 33 ++++----
arch/powerpc/mm/numa.c | 7 +-
arch/powerpc/mm/pgtable_32.c | 8 +-
arch/riscv/mm/init.c | 36 +++------
arch/riscv/mm/kasan_init.c | 10 +--
arch/s390/kernel/setup.c | 27 ++++---
arch/s390/mm/page-states.c | 6 +-
arch/s390/mm/vmem.c | 7 +-
arch/sh/mm/init.c | 9 +--
arch/sparc/mm/init_64.c | 12 +--
arch/x86/kernel/setup.c | 56 +++++---------
arch/x86/mm/numa.c | 2 +-
arch/xtensa/mm/init.c | 55 +++-----------
drivers/bus/mvebu-mbus.c | 12 +--
drivers/irqchip/irq-gic-v3-its.c | 2 +-
include/linux/memblock.h | 88 +++++++++++++---------
kernel/dma/contiguous.c | 11 +--
mm/memblock.c | 95 ++++++++++--------------
mm/page_alloc.c | 11 ++-
mm/sparse.c | 10 +--
48 files changed, 387 insertions(+), 562 deletions(-)
--
2.26.2
^ permalink raw reply
* Flushing transparent hugepages
From: Matthew Wilcox @ 2020-08-18 15:07 UTC (permalink / raw)
To: linux-arch
Cc: Thomas Bogendoerfer, Vineet Gupta, linuxppc-dev, Russell King,
linux-mips, linux-mm, Paul Mackerras, Catalin Marinas, sparclinux,
linux-snps-arc, Will Deacon, David S. Miller, linux-arm-kernel
If your arch does not support HAVE_ARCH_TRANSPARENT_HUGEPAGE, you can
stop reading now. Although maybe you're curious about adding support.
$ git grep -w HAVE_ARCH_TRANSPARENT_HUGEPAGE arch
arch/Kconfig:config HAVE_ARCH_TRANSPARENT_HUGEPAGE
arch/arc/Kconfig:config HAVE_ARCH_TRANSPARENT_HUGEPAGE
arch/arm/Kconfig:config HAVE_ARCH_TRANSPARENT_HUGEPAGE
arch/arm64/Kconfig: select HAVE_ARCH_TRANSPARENT_HUGEPAGE
arch/mips/Kconfig: select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES
arch/powerpc/platforms/Kconfig.cputype: select HAVE_ARCH_TRANSPARENT_HUGEPAGE
arch/s390/Kconfig: select HAVE_ARCH_TRANSPARENT_HUGEPAGE
arch/sparc/Kconfig: select HAVE_ARCH_TRANSPARENT_HUGEPAGE
arch/x86/Kconfig: select HAVE_ARCH_TRANSPARENT_HUGEPAGE
If your arch does not implement flush_dcache_page(), you can also
stop reading.
$ for i in arc arm arm64 mips powerpc s390 sparc x86; do git grep -l flush_dcache_page arch/$i/include; done
arch/arc/include/asm/cacheflush.h
arch/arm/include/asm/cacheflush.h
arch/arm64/include/asm/cacheflush.h
arch/mips/include/asm/cacheflush.h
arch/powerpc/include/asm/cacheflush.h
arch/sparc/include/asm/cacheflush_32.h
arch/sparc/include/asm/cacheflush_64.h
arch/sparc/include/asm/pgtable_64.h
OK, so we're down to arc, arm, arm64, mips, powerpc & sparc. Hi! ;-)
I'm working on adding THP support for filesystems with storage backing
and part of that is expanding the definition of THP to be any order
(ie any power of two of PAGE_SIZE). Now, shmem already has some calls
to flush_dcache_page() for THPs, for example:
if (sgp != SGP_WRITE && !PageUptodate(page)) {
struct page *head = compound_head(page);
int i;
for (i = 0; i < compound_nr(head); i++) {
clear_highpage(head + i);
flush_dcache_page(head + i);
}
SetPageUptodate(head);
}
where you'll be called once for each subpage. But ... these are error
paths, and I'm sure you all diligently test cache coherency scenarios
of error paths in shmem ... right?
For example, arm64 seems confused in this scenario:
void flush_dcache_page(struct page *page)
{
if (test_bit(PG_dcache_clean, &page->flags))
clear_bit(PG_dcache_clean, &page->flags);
}
...
void __sync_icache_dcache(pte_t pte)
{
struct page *page = pte_page(pte);
if (!test_and_set_bit(PG_dcache_clean, &page->flags))
sync_icache_aliases(page_address(page), page_size(page));
}
So arm64 keeps track on a per-page basis which ones have been flushed.
page_size() will return PAGE_SIZE if called on a tail page or regular
page, but will return PAGE_SIZE << compound_order if called on a head
page. So this will either over-flush, or it's missing the opportunity
to clear the bits on all the subpages which have now been flushed.
PowerPC has special handling of hugetlbfs pages. Well, that's what
the config option says, but actually it handles THP as well. If
the config option is enabled.
#ifdef CONFIG_HUGETLB_PAGE
if (PageCompound(page)) {
flush_dcache_icache_hugepage(page);
return;
}
#endif
By the way, THPs can be mapped askew -- that is, at an offset which
means you can't use a PMD to map a PMD sized page.
Anyway, we don't really have consensus between the various architectures
on how to handle either THPs or hugetlb pages. It's not contemplated
in Documentation/core-api/cachetlb.rst so there's no real surprise
we've diverged.
What would you _like_ to see? Would you rather flush_dcache_page()
were called once for each subpage, or would you rather maintain
the page-needs-flushing state once per compound page? We could also
introduce flush_dcache_thp() if some architectures would prefer it one
way and one the other, although that brings into question what to do
for hugetlbfs pages.
It might not be a bad idea to centralise the handling of all this stuff
somewhere. Sounds like the kind of thing Arnd would like to do ;-) I'll
settle for getting enough clear feedback about what the various arch
maintainers want that I can write a documentation update for cachetlb.rst.
^ permalink raw reply
* Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
From: Christian Zigotzky @ 2020-08-18 14:41 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Darren Stevens, R.T.Dickinson, daniel.vetter, Michel Dänzer,
kvm-ppc@vger.kernel.org, gurchetansingh,
Maling list - DRI developers, mad skateman, linuxppc-dev
In-Reply-To: <20200818081830.d2a2cva4hd2jzwba@sirius.home.kraxel.org>
On 18 August 2020 at 10:18 am, Gerd Hoffmann wrote:
> On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote:
>> Hello
>>
>> I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the
>> VirtIO-GPU (see below) still exists. Therefore we still need the patch (see
>> below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine.
> It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a).
>
> Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which
> in turn should bring it to 5.9-rc2 or -rc3.
>
> take care,
> Gerd
>
Hello Gerd,
I compiled a new kernel with the latest DRM misc updates today. The
patch is included in these updates.
This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV
machine on my X5000.
Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8")
with a resolution of 640x480. If I set a higher resolution then the
guest disables the monitor.
I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU.
Please check the latest DRM updates.
Thanks,
Christian
^ permalink raw reply
* Re: [PATCH v2] powerpc/pseries/hotplug-cpu: wait indefinitely for vCPU death
From: Michael Ellerman @ 2020-08-18 13:58 UTC (permalink / raw)
To: Michael Roth, linuxppc-dev
Cc: Nathan Lynch, Greg Kurz, Thiago Jung Bauermann, Cedric Le Goater
In-Reply-To: <20200811161544.10513-1-mdroth@linux.vnet.ibm.com>
On Tue, 11 Aug 2020 11:15:44 -0500, Michael Roth wrote:
> For a power9 KVM guest with XIVE enabled, running a test loop
> where we hotplug 384 vcpus and then unplug them, the following traces
> can be seen (generally within a few loops) either from the unplugged
> vcpu:
>
> [ 1767.353447] cpu 65 (hwid 65) Ready to die...
> [ 1767.952096] Querying DEAD? cpu 66 (66) shows 2
> [ 1767.952311] list_del corruption. next->prev should be c00a000002470208, but was c00a000002470048
> [ 1767.952322] ------------[ cut here ]------------
> [ 1767.952323] kernel BUG at lib/list_debug.c:56!
> [ 1767.952325] Oops: Exception in kernel mode, sig: 5 [#1]
> [ 1767.952326] LE SMP NR_CPUS=2048 NUMA pSeries
> [ 1767.952328] Modules linked in: fuse nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat_ipv6 nf_nat_ipv6 nft_chain_route_ipv6 nft_chain_nat_ipv4 nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_chain_route_ipv4 ip6_tables nft_compat ip_set nf_tables nfnetlink uio_pdrv_genirq ip_tables xfs libcrc32c sd_mod sg xts vmx_crypto virtio_net net_failover failover virtio_scsi dm_multipath dm_mirror dm_region_hash dm_log dm_mod be2iscsi bnx2i cnic uio cxgb4i cxgb4 libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
> [ 1767.952352] CPU: 66 PID: 0 Comm: swapper/66 Kdump: loaded Not tainted 4.18.0-221.el8.ppc64le #1
> [ 1767.952354] NIP: c0000000007ab50c LR: c0000000007ab508 CTR: 00000000000003ac
> [ 1767.952355] REGS: c0000009e5a17840 TRAP: 0700 Not tainted (4.18.0-221.el8.ppc64le)
> [ 1767.952355] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28000842 XER: 20040000
> [ 1767.952360] CFAR: c0000000001ffe64 IRQMASK: 1
> [ 1767.952360] GPR00: c0000000007ab508 c0000009e5a17ac0 c000000001ac0700 0000000000000054
> [ 1767.952360] GPR04: c0000009f056cf90 c0000009f05f5628 c0000009ed40d654 c000000001c90700
> [ 1767.952360] GPR08: 0000000000000007 c0000009f0573980 00000009ef2b0000 7562202c38303230
> [ 1767.952360] GPR12: 0000000000000000 c0000007fff6ce80 c00a000002470208 0000000000000000
> [ 1767.952360] GPR16: 0000000000000001 c0000009f05fbb00 0000000000000800 c0000009ff3d4980
> [ 1767.952360] GPR20: c0000009f05fbb10 5deadbeef0000100 5deadbeef0000200 0000000000187961
> [ 1767.952360] GPR24: c0000009e5a17b78 0000000000000000 0000000000000001 ffffffffffffffff
> [ 1767.952360] GPR28: c00a000002470200 c0000009f05fbb10 c0000009f05fbb10 0000000000000000
> [ 1767.952375] NIP [c0000000007ab50c] __list_del_entry_valid+0xac/0x100
> [ 1767.952376] LR [c0000000007ab508] __list_del_entry_valid+0xa8/0x100
> [ 1767.952377] Call Trace:
> [ 1767.952378] [c0000009e5a17ac0] [c0000000007ab508] __list_del_entry_valid+0xa8/0x100 (unreliable)
> [ 1767.952381] [c0000009e5a17b20] [c000000000476e18] free_pcppages_bulk+0x1f8/0x940
> [ 1767.952383] [c0000009e5a17c20] [c00000000047a9a0] free_unref_page+0xd0/0x100
> [ 1767.952386] [c0000009e5a17c50] [c0000000000bc2a8] xive_spapr_cleanup_queue+0x148/0x1b0
> [ 1767.952388] [c0000009e5a17cf0] [c0000000000b96dc] xive_teardown_cpu+0x1bc/0x240
> [ 1767.952391] [c0000009e5a17d30] [c00000000010bf28] pseries_mach_cpu_die+0x78/0x2f0
> [ 1767.952393] [c0000009e5a17de0] [c00000000005c8d8] cpu_die+0x48/0x70
> [ 1767.952394] [c0000009e5a17e00] [c000000000021cf0] arch_cpu_idle_dead+0x20/0x40
> [ 1767.952397] [c0000009e5a17e20] [c0000000001b4294] do_idle+0x2f4/0x4c0
> [ 1767.952399] [c0000009e5a17ea0] [c0000000001b46a8] cpu_startup_entry+0x38/0x40
> [ 1767.952400] [c0000009e5a17ed0] [c00000000005c43c] start_secondary+0x7bc/0x8f0
> [ 1767.952403] [c0000009e5a17f90] [c00000000000ac70] start_secondary_prolog+0x10/0x14
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/pseries/hotplug-cpu: wait indefinitely for vCPU death
https://git.kernel.org/powerpc/c/801980f6497946048709b9b09771a1729551d705
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/kasan: Fix KASAN_SHADOW_START on BOOK3S_32
From: Michael Ellerman @ 2020-08-18 13:58 UTC (permalink / raw)
To: Paul Mackerras, Christophe Leroy, Michael Ellerman,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <6eddca2d5611fd57312a88eae31278c87a8fc99d.1596641224.git.christophe.leroy@csgroup.eu>
On Wed, 5 Aug 2020 15:27:29 +0000 (UTC), Christophe Leroy wrote:
> On BOOK3S_32, when we have modules and strict kernel RWX, modules
> are not in vmalloc space but in a dedicated segment that is
> below PAGE_OFFSET.
>
> So KASAN_SHADOW_START must take it into account.
>
> MODULES_VADDR can't be used because it is not defined yet
> in kasan.h
Applied to powerpc/fixes.
[1/1] powerpc/kasan: Fix KASAN_SHADOW_START on BOOK3S_32
https://git.kernel.org/powerpc/c/48d2f0407be7a36e8f20be37ec9121e021ef3964
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/fixmap: Fix the size of the early debug area
From: Michael Ellerman @ 2020-08-18 13:58 UTC (permalink / raw)
To: Paul Mackerras, Christophe Leroy, Michael Ellerman,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <996184974d674ff984643778cf1cdd7fe58cc065.1597644194.git.christophe.leroy@csgroup.eu>
On Mon, 17 Aug 2020 06:03:26 +0000 (UTC), Christophe Leroy wrote:
> Commit ("03fd42d458fb powerpc/fixmap: Fix FIX_EARLY_DEBUG_BASE when
> page size is 256k") reworked the setup of the early debug area and
> mistakenly replaced 128 * 1024 by SZ_128.
>
> Change to SZ_128K to restore the original 128 kbytes size of the area.
Applied to powerpc/fixes.
[1/1] powerpc/fixmap: Fix the size of the early debug area
https://git.kernel.org/powerpc/c/fdc6edbb31fba76fd25d7bd016b675a92908d81e
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pkeys: Fix build error with PPC_MEM_KEYS disabled
From: Michael Ellerman @ 2020-08-18 13:58 UTC (permalink / raw)
To: linuxppc-dev, mpe, Aneesh Kumar K.V
In-Reply-To: <20200817103301.158836-1-aneesh.kumar@linux.ibm.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 729 bytes --]
On Mon, 17 Aug 2020 16:03:01 +0530, Aneesh Kumar K.V wrote:
> IS_ENABLED() instead of #ifdef still requires variable declaration.
> In this specific case, default_uamor is declared in asm/pkeys.h which
> is only included if PPC_MEM_KEYS is enabled.
>
> arch/powerpc/mm/book3s64/hash_utils.c: In function ‘hash__early_init_mmu_secondary’:
> arch/powerpc/mm/book3s64/hash_utils.c:1119:21: error: ‘default_uamor’ undeclared (first use in this function)
> 1119 | mtspr(SPRN_UAMOR, default_uamor);
> | ^~~~~~~~~~~~~
Applied to powerpc/fixes.
[1/1] powerpc/pkeys: Fix build error with PPC_MEM_KEYS disabled
https://git.kernel.org/powerpc/c/1e4e4bcaf70ec89f8b499c93a83d078c1e5c0ea6
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Fix is_module_segment() when MODULES_VADDR is defined
From: Michael Ellerman @ 2020-08-18 13:58 UTC (permalink / raw)
To: Paul Mackerras, Christophe Leroy, Michael Ellerman,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <07884ed033c31e074747b7eb8eaa329d15db07ec.1596641219.git.christophe.leroy@csgroup.eu>
On Wed, 5 Aug 2020 15:27:28 +0000 (UTC), Christophe Leroy wrote:
> When MODULES_VADDR is defined, is_module_segment() shall check the
> address against it instead of checking agains VMALLOC_START.
Applied to powerpc/fixes.
[1/1] powerpc/32s: Fix is_module_segment() when MODULES_VADDR is defined
https://git.kernel.org/powerpc/c/7bee31ad8e2f6c276f36993346ac70f4d4c80e45
cheers
^ permalink raw reply
* Re: [powerpc] 5.9.0-rc1 boot failure on POWER9 PowerVM LPAR
From: Michael Ellerman @ 2020-08-18 12:41 UTC (permalink / raw)
To: Sachin Sant, linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <2CD14C97-9145-4D98-8C7C-783B278663A2@linux.vnet.ibm.com>
Sachin Sant <sachinp@linux.vnet.ibm.com> writes:
> 5.9.0-rc1 fails to boot on POWER9 PowerVM LPAR with following message
Looks like:
https://lore.kernel.org/linuxppc-dev/20200814150509.225615-1-vaibhav@linux.ibm.com/
cheers
> Starting udev Kernel Device Manager...
> [ OK ] Started udev Kernel Device Manager.
> BUG: Kernel NULL pointer dereference on read at 0x00000188
> Faulting instruction address: 0xc0000000005417e0
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in: papr_scm(+) uio_pdrv_genirq uio sch_fq_codel ip_tables sd_mod t10_pi ibmvscsi scsi_transport_srp ibmveth
> CPU: 14 PID: 7 Comm: kworker/u32:0 Not tainted 5.9.0-rc1-00085-g06a4ec1d9dc6 #1
> Workqueue: events_unbound async_run_entry_fn
> NIP: c0000000005417e0 LR: c000000000541784 CTR: c000000000871e30
> REGS: c00000067871b710 TRAP: 0300 Not tainted (5.9.0-rc1-00085-g06a4ec1d9dc6)
> MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24822484 XER: 00000000
> CFAR: c00000000054178c DAR: 0000000000000188 DSISR: 40000000 IRQMASK: 0
> GPR00: c000000000541784 c00000067871b9a0 c00000000173cb00 0000000000000000
> GPR04: c000000000f9eb50 0000000000000002 0000000000000001 c000000678689000
> GPR08: c000000000d45e20 0000000000000180 0000000000000001 0000000000000220
> GPR12: c000000000871e30 c00000001ec5ba00 c00000000017ba18 c000000678220e00
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 fffffffffffffef7 ffffffffffffee4b
> GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000003
> GPR28: c0000000037eb018 c00000000166f9e8 c00000066992dd80 c000000000d45f00
> NIP [c0000000005417e0] internal_create_group+0x180/0x4e0
> LR [c000000000541784] internal_create_group+0x124/0x4e0
> Call Trace:
> [c00000067871b9a0] [c000000000541784] internal_create_group+0x124/0x4e0 (unreliable)
> [c00000067871ba60] [c000000000541d70] internal_create_groups.part.4+0x70/0x120
> [c00000067871bab0] [c0000000008293d0] device_add+0x470/0x970
> [c00000067871bb70] [c00000000086f028] nd_async_device_register+0x28/0xa0
> [c00000067871bbe0] [c000000000180fec] async_run_entry_fn+0x7c/0x220
> [c00000067871bc70] [c000000000170f20] process_one_work+0x260/0x510
> [c00000067871bd10] [c000000000171258] worker_thread+0x88/0x5e0
> [c00000067871bdb0] [c00000000017bbb4] kthread+0x1a4/0x1b0
> [c00000067871be20] [c00000000000d3d0] ret_from_kernel_thread+0x5c/0x6c
> Instruction dump:
> 7f07c378 38a00000 7fc3f378 4bffe47d 60000000 7c7a1b79 40820218 e93d0009
> 3b7b0001 7f7b07b4 2fa90000 419e0024 <a3490008> 4192ff7c e8890000 38a00000
> ---[ end trace c238dab2fca3582d ]---
>
> Kernel panic - not syncing: Fatal exception
>
> Have attached config
>
> thanks
> -Sachin
^ permalink raw reply
* Re: [PATCH v2] soc: fsl: enable acpi support
From: kernel test robot @ 2020-08-18 11:48 UTC (permalink / raw)
To: Ran Wang, Li Yang
Cc: kbuild-all, Peng Ma, linux-kernel, clang-built-linux, Ran Wang,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20200818063945.40631-1-ran.wang_1@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]
Hi Ran,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.9-rc1 next-20200818]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Ran-Wang/soc-fsl-enable-acpi-support/20200818-144909
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 06a4ec1d9dc652e17ee3ac2ceb6c7cf6c2b75cdd
config: arm64-randconfig-r005-20200818 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 790878f291fa5dc58a1c560cb6cc76fd1bfd1c5a)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> drivers/soc/fsl/rcpm.c:144:36: warning: unused variable 'rcpm_imx_acpi_ids' [-Wunused-const-variable]
static const struct acpi_device_id rcpm_imx_acpi_ids[] = {
^
1 warning generated.
# https://github.com/0day-ci/linux/commit/c6ed5f2017b1922f30f745a6a6330e1e53caea39
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Ran-Wang/soc-fsl-enable-acpi-support/20200818-144909
git checkout c6ed5f2017b1922f30f745a6a6330e1e53caea39
vim +/rcpm_imx_acpi_ids +144 drivers/soc/fsl/rcpm.c
143
> 144 static const struct acpi_device_id rcpm_imx_acpi_ids[] = {
145 {"NXP0015",},
146 { }
147 };
148 MODULE_DEVICE_TABLE(acpi, rcpm_imx_acpi_ids);
149
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 42989 bytes --]
^ permalink raw reply
* Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
From: Christian Zigotzky @ 2020-08-18 11:08 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Darren Stevens, R.T.Dickinson, daniel.vetter, Michel Dänzer,
kvm-ppc@vger.kernel.org, Maling list - DRI developers,
mad skateman, linuxppc-dev
In-Reply-To: <20200818081830.d2a2cva4hd2jzwba@sirius.home.kraxel.org>
On 18 August 2020 at 10:18 am, Gerd Hoffmann wrote:
> On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote:
>> Hello
>>
>> I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the
>> VirtIO-GPU (see below) still exists. Therefore we still need the patch (see
>> below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine.
> It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a).
>
> Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which
> in turn should bring it to 5.9-rc2 or -rc3.
>
> take care,
> Gerd
>
Thank you!
^ permalink raw reply
* Re: [PATCH 00/10] sound: convert tasklets to use new tasklet_setup()
From: Takashi Iwai @ 2020-08-18 10:59 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, keescook, timur, Xiubo.Lee, linux-kernel, clemens,
tiwai, o-takashi, nicoleotsuka, Allen Pais, Allen Pais, perex,
linuxppc-dev
In-Reply-To: <20200818104432.GB5337@sirena.org.uk>
On Tue, 18 Aug 2020 12:44:32 +0200,
Mark Brown wrote:
>
> On Tue, Aug 18, 2020 at 12:25:31PM +0200, Takashi Iwai wrote:
>
> > Mark, may I apply those ASoC patches through my tree together with
> > others? Those seem targeting to 5.9, and I have a patch set to
> > convert to tasklet for 5.10, which would be better manageable when
> > based on top of those changes.
>
> These patches which I wasn't CCed on and which need their subject lines
> fixing :( . With the subject lines fixed I guess so so
>
> Acked-by: Mark Brown <broonie@kernel.org>
>
> but judging from some of the other threads about similar patches that I
> was randomly CCed on I'm not sure people like from_tasklet() so perhaps
> there might be issues.
Indeed, now I noticed some complaints through other threads, too.
It's no urgent changes but something preferred to be merged in 5.9.
Let's see how the things settled.
thanks,
Takashi
^ permalink raw reply
* [PATCH] powerpc/pseries: Do not initiate shutdown when system is running on UPS
From: Vasant Hegde @ 2020-08-18 10:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Vasant Hegde, stable
As per PAPR specification whenever system is running on UPS we have to
wait for predefined time (default 10mins) before initiating shutdown.
We have user space tool (rtas_errd) to monitor for EPOW events and
initiate shutdown after predefined time. Hence do not initiate shutdown
whenever we get EPOW_SHUTDOWN_ON_UPS event.
Fixes: 79872e35 (powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown)
Cc: stable@vger.kernel.org # v4.0+
Cc: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/ras.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
index f3736fcd98fc..13c86a292c6d 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -184,7 +184,6 @@ static void handle_system_shutdown(char event_modifier)
case EPOW_SHUTDOWN_ON_UPS:
pr_emerg("Loss of system power detected. System is running on"
" UPS/battery. Check RTAS error log for details\n");
- orderly_poweroff(true);
break;
case EPOW_SHUTDOWN_LOSS_OF_CRITICAL_FUNCTIONS:
--
2.26.2
^ permalink raw reply related
* Re: [PATCH 00/10] sound: convert tasklets to use new tasklet_setup()
From: Mark Brown @ 2020-08-18 10:44 UTC (permalink / raw)
To: Takashi Iwai
Cc: alsa-devel, keescook, timur, Xiubo.Lee, linux-kernel, clemens,
tiwai, o-takashi, nicoleotsuka, Allen Pais, Allen Pais, perex,
linuxppc-dev
In-Reply-To: <s5hsgckl084.wl-tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
On Tue, Aug 18, 2020 at 12:25:31PM +0200, Takashi Iwai wrote:
> Mark, may I apply those ASoC patches through my tree together with
> others? Those seem targeting to 5.9, and I have a patch set to
> convert to tasklet for 5.10, which would be better manageable when
> based on top of those changes.
These patches which I wasn't CCed on and which need their subject lines
fixing :( . With the subject lines fixed I guess so so
Acked-by: Mark Brown <broonie@kernel.org>
but judging from some of the other threads about similar patches that I
was randomly CCed on I'm not sure people like from_tasklet() so perhaps
there might be issues.
Allen, as documented in submitting-patches.rst please send patches to
the maintainers for the code you would like to change. The normal
kernel workflow is that people apply patches from their inboxes, if they
aren't copied they are likely to not see the patch at all and it is much
more difficult to apply patches.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 00/10] sound: convert tasklets to use new tasklet_setup()
From: Takashi Iwai @ 2020-08-18 10:25 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, keescook, timur, Xiubo.Lee, linux-kernel, clemens,
tiwai, o-takashi, nicoleotsuka, Allen Pais, Allen Pais, perex,
linuxppc-dev
In-Reply-To: <20200817085703.25732-1-allen.cryptic@gmail.com>
On Mon, 17 Aug 2020 10:56:53 +0200,
Allen Pais wrote:
>
> From: Allen Pais <allen.lkml@gmail.com>
>
> Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> introduced a new tasklet initialization API. This series converts
> all the sound drivers to use the new tasklet_setup() API
>
> Allen Pais (10):
> sound: core: convert tasklets to use new tasklet_setup() API
> sound: firewire: convert tasklets to use new tasklet_setup() API
> sound: asihpi: convert tasklets to use new tasklet_setup() API
> sound: riptide: convert tasklets to use new tasklet_setup() API
> sound: rm9652: convert tasklets to use new tasklet_setup() API
> sound/soc: fsl_esai: convert tasklets to use new tasklet_setup() API
> sound/soc: sh: convert tasklets to use new tasklet_setup() API
> sound/soc: txx9: convert tasklets to use new tasklet_setup() API
Mark, may I apply those ASoC patches through my tree together with
others? Those seem targeting to 5.9, and I have a patch set to
convert to tasklet for 5.10, which would be better manageable when
based on top of those changes.
thanks,
Takashi
> sound: midi: convert tasklets to use new tasklet_setup() API
> sound: ua101: convert tasklets to use new tasklet_setup() API
>
> sound/core/timer.c | 7 +++----
> sound/firewire/amdtp-stream.c | 8 ++++----
> sound/pci/asihpi/asihpi.c | 9 ++++-----
> sound/pci/riptide/riptide.c | 6 +++---
> sound/pci/rme9652/hdsp.c | 6 +++---
> sound/pci/rme9652/hdspm.c | 7 +++----
> sound/soc/fsl/fsl_esai.c | 7 +++----
> sound/soc/sh/siu_pcm.c | 10 ++++------
> sound/soc/txx9/txx9aclc.c | 7 +++----
> sound/usb/midi.c | 7 +++----
> sound/usb/misc/ua101.c | 7 +++----
> 11 files changed, 36 insertions(+), 45 deletions(-)
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 00/10] sound: convert tasklets to use new tasklet_setup()
From: Allen @ 2020-08-18 9:31 UTC (permalink / raw)
To: Takashi Iwai
Cc: alsa-devel, Kees Cook, timur, Xiubo.Lee, linux-kernel, clemens,
tiwai, o-takashi, nicoleotsuka, Allen Pais, perex, linuxppc-dev
In-Reply-To: <s5hk0xxppz6.wl-tiwai@suse.de>
>
> Well, then at the next time, please mention it explicitly in the cover
> letter. Usually this kind of API conversion isn't done during rc. Or
> it's done systematically via script or such. So unless mentioned,
> it's not expected to be carried to 5.9.
Sorry for having missed the detail. Will take care of it in the future.
>
> In anyway, if the final purpose is to drop the old tasklet API and
> that's the plan for 5.9, all tree-wide changes have to be done in
> 5.9 beforehand. Was that the decision?
The idea was to land the tree-wide changes as part of 5.9
>
> > > I have a patch set to drop the whole tasklet usage in sound/*
> > > (destined for 5.10, to be submitted soon), so if that's for 5.10,
> > > it'll be likely superfluous.
> >
> > I have picked patches from your tree to adapt to this new API.
> > Those can be picked in 5.10 I suppose.
>
> Adapting the changes are trivial, don't worry. It was just a question
> of how to organize changes.
Sure, Thank you.
- Allen
^ permalink raw reply
* Re: [PATCH 06/20] ethernet: chelsio: convert tasklets to use new tasklet_setup() API
From: Allen @ 2020-08-18 9:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: jes, borisp, Kees Cook, linux-rdma, netdev, kda, cooldavid,
dougmill, linux-kernel, linux-acenic, oss-drivers, Romain Perier,
linuxppc-dev, David Miller, linux-arm-kernel, mlindner
In-Reply-To: <20200817083216.5367f56a@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
>
> You need to adjust kdoc when you change functions:
>
> drivers/net/ethernet/chelsio/cxgb4/sge.c:2664: warning: Function parameter or member 't' not described in 'restart_ctrlq'
> drivers/net/ethernet/chelsio/cxgb4/sge.c:2664: warning: Excess function parameter 'data' description in 'restart_ctrlq'
> drivers/net/ethernet/chelsio/cxgb4/sge.c:2965: warning: Function parameter or member 't' not described in 'restart_ofldq'
> drivers/net/ethernet/chelsio/cxgb4/sge.c:2965: warning: Excess function parameter 'data' description in 'restart_ofldq'
Thanks, will fix it and spin V2.
--
- Allen
^ permalink raw reply
* Re: [PATCH v2 1/3] powerpc/numa: Introduce logical numa id
From: Aneesh Kumar K.V @ 2020-08-18 8:21 UTC (permalink / raw)
To: Srikar Dronamraju; +Cc: Nathan Lynch, linuxppc-dev
In-Reply-To: <20200817114908.GA32655@linux.vnet.ibm.com>
Srikar Dronamraju <srikar@linux.vnet.ibm.com> writes:
> * Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> [2020-08-17 17:04:24]:
>
>> On 8/17/20 4:29 PM, Srikar Dronamraju wrote:
>> > * Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> [2020-08-17 16:02:36]:
>> >
>> > > We use ibm,associativity and ibm,associativity-lookup-arrays to derive the numa
>> > > node numbers. These device tree properties are firmware indicated grouping of
>> > > resources based on their hierarchy in the platform. These numbers (group id) are
>> > > not sequential and hypervisor/firmware can follow different numbering schemes.
>> > > For ex: on powernv platforms, we group them in the below order.
>> > >
>> > > * - CCM node ID
>> > > * - HW card ID
>> > > * - HW module ID
>> > > * - Chip ID
>> > > * - Core ID
>> > >
>> > > Based on ibm,associativity-reference-points we use one of the above group ids as
>> > > Linux NUMA node id. (On PowerNV platform Chip ID is used). This results
>> > > in Linux reporting non-linear NUMA node id and which also results in Linux
>> > > reporting empty node 0 NUMA nodes.
>> > >
>> > > This can be resolved by mapping the firmware provided group id to a logical Linux
>> > > NUMA id. In this patch, we do this only for pseries platforms considering the
>> > > firmware group id is a virtualized entity and users would not have drawn any
>> > > conclusion based on the Linux Numa Node id.
>> > >
>> > > On PowerNV platform since we have historically mapped Chip ID as Linux NUMA node
>> > > id, we keep the existing Linux NUMA node id numbering.
>> >
>> > I still dont understand how you are going to handle numa distances.
>> > With your patch, have you tried dlpar add/remove on a sparsely noded machine?
>> >
>>
>> We follow the same steps when fetching distance information. Instead of
>> using affinity domain id, we now use the mapped node id. The relevant hunk
>> in the patch is
>>
>> + nid = affinity_domain_to_nid(&domain);
>>
>> if (nid > 0 &&
>> - of_read_number(associativity, 1) >= distance_ref_points_depth) {
>> + of_read_number(associativity, 1) >= distance_ref_points_depth) {
>> /*
>> * Skip the length field and send start of associativity array
>> */
>>
>> I haven't tried dlpar add/remove. I don't have a setup to try that. Do you
>> see a problem there?
>>
>
> Yes, I think there can be 2 problems.
>
> 1. distance table may be filled with incorrect data.
> 2. numactl -H distance table shows symmetric data, the symmetric nature may
> be lost.
>
After discussing with srikar to understand these concern better, below
are the conclusions.
1) There is no corruption of node distance. We do handle node distance
correctly. But the numactl -H output can be such that we won't find the
numa nodes with a higher number to be further away from node 0. ie. We can
find output like below.
node 0 1 2 3
0: 10 40 40 20
1: 40 10 40 40
2: 40 40 10 40
3: 20 40 40 10
Here node 3 is closer to node 0 Than node 1 and 2. I am not sure this
is going to break any userspace.
2) We can find node number changing if we do a DLPAR add of memory/cpu
and reboot. ie, we boot with resource domain id 4 and 6 and then later
add resources from domain 5. In this above case, we will have node 0,1
and 2 mapping domain id 4, 6, 5. On reboot, we can map them such that
node 0 -> 4
node 1 -> 5
node 2 -> 6
I guess this is still ok because we are running in a virtualized
environment and node numbers to domain id are never guaranteed to be he
same across reboot.
-aneesh
^ permalink raw reply
* Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
From: Gerd Hoffmann @ 2020-08-18 8:18 UTC (permalink / raw)
To: Christian Zigotzky
Cc: Darren Stevens, R.T.Dickinson, daniel.vetter, Michel Dänzer,
kvm-ppc@vger.kernel.org, Maling list - DRI developers,
mad skateman, linuxppc-dev
In-Reply-To: <3eee8130-6913-49d2-2160-abf0bf17c44e@xenosoft.de>
On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote:
> Hello
>
> I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the
> VirtIO-GPU (see below) still exists. Therefore we still need the patch (see
> below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine.
It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a).
Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which
in turn should bring it to 5.9-rc2 or -rc3.
take care,
Gerd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox