* [PATCH v3 03/19] powerpc: Move `path` variable inside DEBUG_PROM
From: Mathieu Malaterre @ 2018-04-04 20:08 UTC (permalink / raw)
To: Michael Ellerman
Cc: Christophe Leroy, Mathieu Malaterre, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20180328193307.978-1-malat@debian.org>
Add gcc attribute unused for two variables. Fix warnings treated as errors
with W=1:
arch/powerpc/kernel/prom_init.c:1388:8: error: variable ‘path’ set but not used [-Werror=unused-but-set-variable]
Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
v3: really move path within ifdef DEBUG_PROM
v2: move path within ifdef DEBUG_PROM
arch/powerpc/kernel/prom_init.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index acf4b2e0530c..223b35acbbdd 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -603,7 +603,7 @@ static void __init early_cmdline_parse(void)
const char *opt;
char *p;
- int l = 0;
+ int l __maybe_unused = 0;
prom_cmd_line[0] = 0;
p = prom_cmd_line;
@@ -1385,7 +1385,10 @@ static void __init reserve_mem(u64 base, u64 size)
static void __init prom_init_mem(void)
{
phandle node;
- char *path, type[64];
+#ifdef DEBUG_PROM
+ char *path;
+#endif
+ char type[64];
unsigned int plen;
cell_t *p, *endp;
__be32 val;
@@ -1406,7 +1409,9 @@ static void __init prom_init_mem(void)
prom_debug("root_size_cells: %x\n", rsc);
prom_debug("scanning memory:\n");
+#ifdef DEBUG_PROM
path = prom_scratch;
+#endif
for (node = 0; prom_next_node(&node); ) {
type[0] = 0;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 01/19] powerpc/powermac: Mark variable x as unused
From: Mathieu Malaterre @ 2018-04-04 20:07 UTC (permalink / raw)
To: Michael Ellerman
Cc: Christophe Leroy, Mathieu Malaterre, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20180328192717.656-1-malat@debian.org>
Since the value of x is never intended to be read, declare it with gcc
attribute as unused. Fix warning treated as error with W=1:
arch/powerpc/platforms/powermac/bootx_init.c:471:21: error: variable ‘x’ set but not used [-Werror=unused-but-set-variable]
Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
v3: style: add missing empty line after declaration
v2: move x variable within its local scope
arch/powerpc/platforms/powermac/bootx_init.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powermac/bootx_init.c b/arch/powerpc/platforms/powermac/bootx_init.c
index c3c9bbb3573a..ba0964c17620 100644
--- a/arch/powerpc/platforms/powermac/bootx_init.c
+++ b/arch/powerpc/platforms/powermac/bootx_init.c
@@ -468,7 +468,7 @@ void __init bootx_init(unsigned long r3, unsigned long r4)
boot_infos_t *bi = (boot_infos_t *) r4;
unsigned long hdr;
unsigned long space;
- unsigned long ptr, x;
+ unsigned long ptr;
char *model;
unsigned long offset = reloc_offset();
@@ -562,6 +562,8 @@ void __init bootx_init(unsigned long r3, unsigned long r4)
* MMU switched OFF, so this should not be useful anymore.
*/
if (bi->version < 4) {
+ unsigned long x __maybe_unused;
+
bootx_printf("Touching pages...\n");
/*
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] powerpc/fadump: Do not use hugepages when fadump is active
From: Hari Bathini @ 2018-04-04 17:13 UTC (permalink / raw)
To: Michael Ellerman
Cc: Mahesh J Salgaonkar, linuxppc-dev, Aneesh Kumar K.V,
Anshuman Khandual
In-Reply-To: <152286202560.2738.7385812464895685351.stgit@hbathini.in.ibm.com>
FADump capture kernel boots in a restricted memory environment saving the
context of previous kernel to capture vmcore. Having hugepages support in
such environment would make things unnecessarily complicated, as hugepages
need memory set aside for them and this would mean too much memory wasted
in supporting hugepages in capture kernel. Also, if there is a shortfall
in memory, capture kernel fails to boot. So, disable hugepages when fadump
is active to avoid boot issues in FADump capture kernel.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
---
arch/powerpc/mm/hash_utils_64.c | 11 +++++++++--
arch/powerpc/mm/hugetlbpage.c | 11 +++++++++++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index cf290d41..703cde2 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -571,8 +571,15 @@ static void __init htab_scan_page_sizes(void)
}
#ifdef CONFIG_HUGETLB_PAGE
- /* Reserve 16G huge page memory sections for huge pages */
- of_scan_flat_dt(htab_dt_scan_hugepage_blocks, NULL);
+ /*
+ * FADump capture kernel doesn't care much about hugepages.
+ * Moreover, handling hugepages in capture kernel is asking
+ * for trouble. So, skip this when fadump is active.
+ */
+ if (!is_fadump_active()) {
+ /* Reserve 16G huge page memory sections for huge pages */
+ of_scan_flat_dt(htab_dt_scan_hugepage_blocks, NULL);
+ }
#endif /* CONFIG_HUGETLB_PAGE */
}
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 876da2b..3d47fb6 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -23,6 +23,7 @@
#include <asm/pgalloc.h>
#include <asm/tlb.h>
#include <asm/setup.h>
+#include <asm/fadump.h>
#include <asm/hugetlb.h>
#include <asm/pte-walk.h>
@@ -653,6 +654,16 @@ static int __init hugetlbpage_init(void)
{
int psize;
+ /*
+ * FADump capture kernel doesn't care much about hugepages.
+ * Moreover, handling hugepages in capture kernel is asking
+ * for trouble. So, skip this when fadump is active.
+ */
+ if (is_fadump_active()) {
+ pr_info("Huge pages are not supported when fadump is active\n");
+ return 0;
+ }
+
#if !defined(CONFIG_PPC_FSL_BOOK3E) && !defined(CONFIG_PPC_8xx)
if (!radix_enabled() && !mmu_has_feature(MMU_FTR_16M_PAGE))
return -ENODEV;
^ permalink raw reply related
* [PATCH 1/2] powerpc/fadump: exclude memory holes while reserving memory in second kernel
From: Hari Bathini @ 2018-04-04 17:13 UTC (permalink / raw)
To: Michael Ellerman
Cc: Mahesh J Salgaonkar, linuxppc-dev, Aneesh Kumar K.V,
Anshuman Khandual
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
The second kernel, during early boot after the crash, reserves rest of
the memory above boot memory size to make sure it does not touch any of the
dump memory area. It uses memblock_reserve() that reserves the specified
memory region irrespective of memory holes present within that region.
There are chances where previous kernel would have hot removed some of
its memory leaving memory holes behind. In such cases fadump kernel reports
incorrect number of reserved pages through arch_reserved_kernel_pages()
hook causing kernel to hang or panic.
Fix this by excluding memory holes while reserving rest of the memory
above boot memory size during second kernel boot after crash.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
---
arch/powerpc/kernel/fadump.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 3c2c268..b5218aa 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -380,7 +380,11 @@ int __init fadump_reserve_mem(void)
memory_boundary = memblock_end_of_DRAM();
if (fw_dump.dump_active) {
- printk(KERN_INFO "Firmware-assisted dump is active.\n");
+ struct memblock_region *reg;
+ unsigned long mstart, mend, msize;
+
+ pr_info("Firmware-assisted dump is active.\n");
+
/*
* If last boot has crashed then reserve all the memory
* above boot_memory_size so that we don't touch it until
@@ -389,11 +393,18 @@ int __init fadump_reserve_mem(void)
*/
base = fw_dump.boot_memory_size;
size = memory_boundary - base;
- memblock_reserve(base, size);
- printk(KERN_INFO "Reserved %ldMB of memory at %ldMB "
- "for saving crash dump\n",
- (unsigned long)(size >> 20),
- (unsigned long)(base >> 20));
+ for_each_memblock(memory, reg) {
+ mstart = max_t(unsigned long, base, reg->base);
+ mend = reg->base + reg->size;
+ mend = min(base + size, mend);
+
+ if (mstart < mend) {
+ msize = mend - mstart;
+ memblock_reserve(mstart, msize);
+ pr_info("Reserved %ldMB of memory at %#016lx for saving crash dump\n",
+ (msize >> 20), mstart);
+ }
+ }
fw_dump.fadumphdr_addr =
be64_to_cpu(fdm_active->rmr_region.destination_address) +
^ permalink raw reply related
* Re: [PATCH v9 15/24] mm: Introduce __vm_normal_page()
From: Laurent Dufour @ 2018-04-04 16:26 UTC (permalink / raw)
To: Jerome Glisse
Cc: paulmck, peterz, akpm, kirill, ak, mhocko, dave, jack,
Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner, Ingo Molnar,
hpa, Will Deacon, Sergey Senozhatsky, Andrea Arcangeli,
Alexei Starovoitov, kemi.wang, sergey.senozhatsky.work,
Daniel Jordan, linux-kernel, linux-mm, haren, khandual, npiggin,
bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <20180403193927.GD5935@redhat.com>
On 03/04/2018 21:39, Jerome Glisse wrote:
> On Tue, Mar 13, 2018 at 06:59:45PM +0100, Laurent Dufour wrote:
>> When dealing with the speculative fault path we should use the VMA's field
>> cached value stored in the vm_fault structure.
>>
>> Currently vm_normal_page() is using the pointer to the VMA to fetch the
>> vm_flags value. This patch provides a new __vm_normal_page() which is
>> receiving the vm_flags flags value as parameter.
>>
>> Note: The speculative path is turned on for architecture providing support
>> for special PTE flag. So only the first block of vm_normal_page is used
>> during the speculative path.
>
> Might be a good idea to explicitly have SPECULATIVE Kconfig option depends
> on ARCH_PTE_SPECIAL and a comment for !HAVE_PTE_SPECIAL in the function
> explaining that speculative page fault should never reach that point.
Unfortunately there is no ARCH_PTE_SPECIAL in the config file, it is defined in
the per architecture header files.
So I can't do anything in the Kconfig file
However, I can check that at build time, and doing such a check in
__vm_normal_page sounds to be a good place, like that:
@@ -869,6 +870,14 @@ struct page *__vm_normal_page(struct vm_area_struct *vma,
unsigned long addr,
/* !HAVE_PTE_SPECIAL case follows: */
+#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
+ /* This part should never get called when the speculative page fault
+ * handler is turned on. This is mainly because we can't rely on
+ * vm_start.
+ */
+#error CONFIG_SPECULATIVE_PAGE_FAULT requires HAVE_PTE_SPECIAL
+#endif
+
if (unlikely(vma_flags & (VM_PFNMAP|VM_MIXEDMAP))) {
if (vma_flags & VM_MIXEDMAP) {
if (!pfn_valid(pfn))
Thanks,
Laurent.
^ permalink raw reply
* Re: [PATCH v9 15/24] mm: Introduce __vm_normal_page()
From: Laurent Dufour @ 2018-04-04 16:04 UTC (permalink / raw)
To: David Rientjes
Cc: paulmck, peterz, akpm, kirill, ak, mhocko, dave, jack,
Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner, Ingo Molnar,
hpa, Will Deacon, Sergey Senozhatsky, Andrea Arcangeli,
Alexei Starovoitov, kemi.wang, sergey.senozhatsky.work,
Daniel Jordan, linux-kernel, linux-mm, haren, khandual, npiggin,
bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <alpine.DEB.2.20.1804021616370.104195@chino.kir.corp.google.com>
On 03/04/2018 01:18, David Rientjes wrote:
> On Tue, 13 Mar 2018, Laurent Dufour wrote:
>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index a84ddc218bbd..73b8b99f482b 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -1263,8 +1263,11 @@ struct zap_details {
>> pgoff_t last_index; /* Highest page->index to unmap */
>> };
>>
>> -struct page *_vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
>> - pte_t pte, bool with_public_device);
>> +struct page *__vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
>> + pte_t pte, bool with_public_device,
>> + unsigned long vma_flags);
>> +#define _vm_normal_page(vma, addr, pte, with_public_device) \
>> + __vm_normal_page(vma, addr, pte, with_public_device, (vma)->vm_flags)
>> #define vm_normal_page(vma, addr, pte) _vm_normal_page(vma, addr, pte, false)
>>
>> struct page *vm_normal_page_pmd(struct vm_area_struct *vma, unsigned long addr,
>
> If _vm_normal_page() is a static inline function does it break somehow?
> It's nice to avoid the #define's.
No problem, I'll create it as a static inline function.
>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index af0338fbc34d..184a0d663a76 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -826,8 +826,9 @@ static void print_bad_pte(struct vm_area_struct *vma, unsigned long addr,
>> #else
>> # define HAVE_PTE_SPECIAL 0
>> #endif
>> -struct page *_vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
>> - pte_t pte, bool with_public_device)
>> +struct page *__vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
>> + pte_t pte, bool with_public_device,
>> + unsigned long vma_flags)
>> {
>> unsigned long pfn = pte_pfn(pte);
>>
>
> Would it be possible to update the comment since the function itself is no
> longer named vm_normal_page?
Sure.
^ permalink raw reply
* Re: [PATCH v9 14/24] mm: Introduce __maybe_mkwrite()
From: Laurent Dufour @ 2018-04-04 15:56 UTC (permalink / raw)
To: David Rientjes
Cc: paulmck, peterz, akpm, kirill, ak, mhocko, dave, jack,
Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner, Ingo Molnar,
hpa, Will Deacon, Sergey Senozhatsky, Andrea Arcangeli,
Alexei Starovoitov, kemi.wang, sergey.senozhatsky.work,
Daniel Jordan, linux-kernel, linux-mm, haren, khandual, npiggin,
bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <alpine.DEB.2.20.1804021611590.102694@chino.kir.corp.google.com>
On 03/04/2018 01:12, David Rientjes wrote:
> On Tue, 13 Mar 2018, Laurent Dufour wrote:
>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index dfa81a638b7c..a84ddc218bbd 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -684,13 +684,18 @@ void free_compound_page(struct page *page);
>> * pte_mkwrite. But get_user_pages can cause write faults for mappings
>> * that do not have writing enabled, when used by access_process_vm.
>> */
>> -static inline pte_t maybe_mkwrite(pte_t pte, struct vm_area_struct *vma)
>> +static inline pte_t __maybe_mkwrite(pte_t pte, unsigned long vma_flags)
>> {
>> - if (likely(vma->vm_flags & VM_WRITE))
>> + if (likely(vma_flags & VM_WRITE))
>> pte = pte_mkwrite(pte);
>> return pte;
>> }
>>
>> +static inline pte_t maybe_mkwrite(pte_t pte, struct vm_area_struct *vma)
>> +{
>> + return __maybe_mkwrite(pte, vma->vm_flags);
>> +}
>> +
>> int alloc_set_pte(struct vm_fault *vmf, struct mem_cgroup *memcg,
>> struct page *page);
>> int finish_fault(struct vm_fault *vmf);
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 0a0a483d9a65..af0338fbc34d 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -2472,7 +2472,7 @@ static inline void wp_page_reuse(struct vm_fault *vmf)
>>
>> flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte));
>> entry = pte_mkyoung(vmf->orig_pte);
>> - entry = maybe_mkwrite(pte_mkdirty(entry), vma);
>> + entry = __maybe_mkwrite(pte_mkdirty(entry), vmf->vma_flags);
>> if (ptep_set_access_flags(vma, vmf->address, vmf->pte, entry, 1))
>> update_mmu_cache(vma, vmf->address, vmf->pte);
>> pte_unmap_unlock(vmf->pte, vmf->ptl);
>> @@ -2549,8 +2549,8 @@ static int wp_page_copy(struct vm_fault *vmf)
>> inc_mm_counter_fast(mm, MM_ANONPAGES);
>> }
>> flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte));
>> - entry = mk_pte(new_page, vma->vm_page_prot);
>> - entry = maybe_mkwrite(pte_mkdirty(entry), vma);
>> + entry = mk_pte(new_page, vmf->vma_page_prot);
>> + entry = __maybe_mkwrite(pte_mkdirty(entry), vmf->vma_flags);
>> /*
>> * Clear the pte entry and flush it first, before updating the
>> * pte with the new entry. This will avoid a race condition
>
> Don't you also need to do this in do_swap_page()?
Indeed I'll drop this patch as all the changes are now done in the patch 11
"mm: Cache some VMA fields in the vm_fault structure" where, as you suggested,
maybe_mkwrite() is now getting passed the vm_flags value directly.
> diff --git a/mm/memory.c b/mm/memory.c
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3067,9 +3067,9 @@ int do_swap_page(struct vm_fault *vmf)
>
> inc_mm_counter_fast(vma->vm_mm, MM_ANONPAGES);
> dec_mm_counter_fast(vma->vm_mm, MM_SWAPENTS);
> - pte = mk_pte(page, vma->vm_page_prot);
> + pte = mk_pte(page, vmf->vma_page_prot);
> if ((vmf->flags & FAULT_FLAG_WRITE) && reuse_swap_page(page, NULL)) {
> - pte = maybe_mkwrite(pte_mkdirty(pte), vma);
> + pte = __maybe_mkwrite(pte_mkdirty(pte), vmf->vma_flags);
> vmf->flags &= ~FAULT_FLAG_WRITE;
> ret |= VM_FAULT_WRITE;
> exclusive = RMAP_EXCLUSIVE;
>
^ permalink raw reply
* Re: [PATCH v9 11/24] mm: Cache some VMA fields in the vm_fault structure
From: Laurent Dufour @ 2018-04-04 15:48 UTC (permalink / raw)
To: David Rientjes
Cc: paulmck, peterz, akpm, kirill, ak, mhocko, dave, jack,
Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner, Ingo Molnar,
hpa, Will Deacon, Sergey Senozhatsky, Andrea Arcangeli,
Alexei Starovoitov, kemi.wang, sergey.senozhatsky.work,
Daniel Jordan, linux-kernel, linux-mm, haren, khandual, npiggin,
bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <alpine.DEB.2.20.1804021523100.249714@chino.kir.corp.google.com>
On 03/04/2018 00:24, David Rientjes wrote:
> On Tue, 13 Mar 2018, Laurent Dufour wrote:
>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index ef6ef0627090..dfa81a638b7c 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -359,6 +359,12 @@ struct vm_fault {
>> * page table to avoid allocation from
>> * atomic context.
>> */
>> + /*
>> + * These entries are required when handling speculative page fault.
>> + * This way the page handling is done using consistent field values.
>> + */
>> + unsigned long vma_flags;
>> + pgprot_t vma_page_prot;
>> };
>>
>> /* page entry size for vm->huge_fault() */
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 446427cafa19..f71db2b42b30 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -3717,6 +3717,8 @@ static int hugetlb_no_page(struct mm_struct *mm, struct vm_area_struct *vma,
>> .vma = vma,
>> .address = address,
>> .flags = flags,
>> + .vma_flags = vma->vm_flags,
>> + .vma_page_prot = vma->vm_page_prot,
>> /*
>> * Hard to debug if it ends up being
>> * used by a callee that assumes
>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>> index 32314e9e48dd..a946d5306160 100644
>> --- a/mm/khugepaged.c
>> +++ b/mm/khugepaged.c
>> @@ -882,6 +882,8 @@ static bool __collapse_huge_page_swapin(struct mm_struct *mm,
>> .flags = FAULT_FLAG_ALLOW_RETRY,
>> .pmd = pmd,
>> .pgoff = linear_page_index(vma, address),
>> + .vma_flags = vma->vm_flags,
>> + .vma_page_prot = vma->vm_page_prot,
>> };
>>
>> /* we only decide to swapin, if there is enough young ptes */
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 0200340ef089..46fe92b93682 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -2615,7 +2615,7 @@ static int wp_page_copy(struct vm_fault *vmf)
>> * Don't let another task, with possibly unlocked vma,
>> * keep the mlocked page.
>> */
>> - if (page_copied && (vma->vm_flags & VM_LOCKED)) {
>> + if (page_copied && (vmf->vma_flags & VM_LOCKED)) {
>> lock_page(old_page); /* LRU manipulation */
>> if (PageMlocked(old_page))
>> munlock_vma_page(old_page);
>
> Doesn't wp_page_copy() also need to pass this to anon_vma_prepare() so
> that find_mergeable_anon_vma() works correctly?
In the case of the spf handler, we check that the vma->anon_vma is not null.
So __anon_vma_prepare(vma) is never called in the context of the SPF handler.
>
>> @@ -2649,7 +2649,7 @@ static int wp_page_copy(struct vm_fault *vmf)
>> */
>> int finish_mkwrite_fault(struct vm_fault *vmf)
>> {
>> - WARN_ON_ONCE(!(vmf->vma->vm_flags & VM_SHARED));
>> + WARN_ON_ONCE(!(vmf->vma_flags & VM_SHARED));
>> if (!pte_map_lock(vmf))
>> return VM_FAULT_RETRY;
>> /*
>> @@ -2751,7 +2751,7 @@ static int do_wp_page(struct vm_fault *vmf)
>> * We should not cow pages in a shared writeable mapping.
>> * Just mark the pages writable and/or call ops->pfn_mkwrite.
>> */
>> - if ((vma->vm_flags & (VM_WRITE|VM_SHARED)) ==
>> + if ((vmf->vma_flags & (VM_WRITE|VM_SHARED)) ==
>> (VM_WRITE|VM_SHARED))
>> return wp_pfn_shared(vmf);
>>
>> @@ -2798,7 +2798,7 @@ static int do_wp_page(struct vm_fault *vmf)
>> return VM_FAULT_WRITE;
>> }
>> unlock_page(vmf->page);
>> - } else if (unlikely((vma->vm_flags & (VM_WRITE|VM_SHARED)) ==
>> + } else if (unlikely((vmf->vma_flags & (VM_WRITE|VM_SHARED)) ==
>> (VM_WRITE|VM_SHARED))) {
>> return wp_page_shared(vmf);
>> }
>> @@ -3067,7 +3067,7 @@ int do_swap_page(struct vm_fault *vmf)
>>
>> inc_mm_counter_fast(vma->vm_mm, MM_ANONPAGES);
>> dec_mm_counter_fast(vma->vm_mm, MM_SWAPENTS);
>> - pte = mk_pte(page, vma->vm_page_prot);
>> + pte = mk_pte(page, vmf->vma_page_prot);
>> if ((vmf->flags & FAULT_FLAG_WRITE) && reuse_swap_page(page, NULL)) {
>> pte = maybe_mkwrite(pte_mkdirty(pte), vma);
>> vmf->flags &= ~FAULT_FLAG_WRITE;
>> @@ -3093,7 +3093,7 @@ int do_swap_page(struct vm_fault *vmf)
>>
>> swap_free(entry);
>> if (mem_cgroup_swap_full(page) ||
>> - (vma->vm_flags & VM_LOCKED) || PageMlocked(page))
>> + (vmf->vma_flags & VM_LOCKED) || PageMlocked(page))
>> try_to_free_swap(page);
>> unlock_page(page);
>> if (page != swapcache && swapcache) {
>> @@ -3150,7 +3150,7 @@ static int do_anonymous_page(struct vm_fault *vmf)
>> pte_t entry;
>>
>> /* File mapping without ->vm_ops ? */
>> - if (vma->vm_flags & VM_SHARED)
>> + if (vmf->vma_flags & VM_SHARED)
>> return VM_FAULT_SIGBUS;
>>
>> /*
>> @@ -3174,7 +3174,7 @@ static int do_anonymous_page(struct vm_fault *vmf)
>> if (!(vmf->flags & FAULT_FLAG_WRITE) &&
>> !mm_forbids_zeropage(vma->vm_mm)) {
>> entry = pte_mkspecial(pfn_pte(my_zero_pfn(vmf->address),
>> - vma->vm_page_prot));
>> + vmf->vma_page_prot));
>> if (!pte_map_lock(vmf))
>> return VM_FAULT_RETRY;
>> if (!pte_none(*vmf->pte))
>> @@ -3207,8 +3207,8 @@ static int do_anonymous_page(struct vm_fault *vmf)
>> */
>> __SetPageUptodate(page);
>>
>> - entry = mk_pte(page, vma->vm_page_prot);
>> - if (vma->vm_flags & VM_WRITE)
>> + entry = mk_pte(page, vmf->vma_page_prot);
>> + if (vmf->vma_flags & VM_WRITE)
>> entry = pte_mkwrite(pte_mkdirty(entry));
>>
>> if (!pte_map_lock(vmf)) {
>> @@ -3404,7 +3404,7 @@ static int do_set_pmd(struct vm_fault *vmf, struct page *page)
>> for (i = 0; i < HPAGE_PMD_NR; i++)
>> flush_icache_page(vma, page + i);
>>
>> - entry = mk_huge_pmd(page, vma->vm_page_prot);
>> + entry = mk_huge_pmd(page, vmf->vma_page_prot);
>> if (write)
>> entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma);
>>
>> @@ -3478,11 +3478,11 @@ int alloc_set_pte(struct vm_fault *vmf, struct mem_cgroup *memcg,
>> return VM_FAULT_NOPAGE;
>>
>> flush_icache_page(vma, page);
>> - entry = mk_pte(page, vma->vm_page_prot);
>> + entry = mk_pte(page, vmf->vma_page_prot);
>> if (write)
>> entry = maybe_mkwrite(pte_mkdirty(entry), vma);
>> /* copy-on-write page */
>> - if (write && !(vma->vm_flags & VM_SHARED)) {
>> + if (write && !(vmf->vma_flags & VM_SHARED)) {
>> inc_mm_counter_fast(vma->vm_mm, MM_ANONPAGES);
>> page_add_new_anon_rmap(page, vma, vmf->address, false);
>> mem_cgroup_commit_charge(page, memcg, false, false);
>> @@ -3521,7 +3521,7 @@ int finish_fault(struct vm_fault *vmf)
>>
>> /* Did we COW the page? */
>> if ((vmf->flags & FAULT_FLAG_WRITE) &&
>> - !(vmf->vma->vm_flags & VM_SHARED))
>> + !(vmf->vma_flags & VM_SHARED))
>> page = vmf->cow_page;
>> else
>> page = vmf->page;
>> @@ -3775,7 +3775,7 @@ static int do_fault(struct vm_fault *vmf)
>> ret = VM_FAULT_SIGBUS;
>> else if (!(vmf->flags & FAULT_FLAG_WRITE))
>> ret = do_read_fault(vmf);
>> - else if (!(vma->vm_flags & VM_SHARED))
>> + else if (!(vmf->vma_flags & VM_SHARED))
>> ret = do_cow_fault(vmf);
>> else
>> ret = do_shared_fault(vmf);
>> @@ -3832,7 +3832,7 @@ static int do_numa_page(struct vm_fault *vmf)
>> * accessible ptes, some can allow access by kernel mode.
>> */
>> pte = ptep_modify_prot_start(vma->vm_mm, vmf->address, vmf->pte);
>> - pte = pte_modify(pte, vma->vm_page_prot);
>> + pte = pte_modify(pte, vmf->vma_page_prot);
>> pte = pte_mkyoung(pte);
>> if (was_writable)
>> pte = pte_mkwrite(pte);
>> @@ -3866,7 +3866,7 @@ static int do_numa_page(struct vm_fault *vmf)
>> * Flag if the page is shared between multiple address spaces. This
>> * is later used when determining whether to group tasks together
>> */
>> - if (page_mapcount(page) > 1 && (vma->vm_flags & VM_SHARED))
>> + if (page_mapcount(page) > 1 && (vmf->vma_flags & VM_SHARED))
>> flags |= TNF_SHARED;
>>
>> last_cpupid = page_cpupid_last(page);
>> @@ -3911,7 +3911,7 @@ static inline int wp_huge_pmd(struct vm_fault *vmf, pmd_t orig_pmd)
>> return vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PMD);
>>
>> /* COW handled on pte level: split pmd */
>> - VM_BUG_ON_VMA(vmf->vma->vm_flags & VM_SHARED, vmf->vma);
>> + VM_BUG_ON_VMA(vmf->vma_flags & VM_SHARED, vmf->vma);
>> __split_huge_pmd(vmf->vma, vmf->pmd, vmf->address, false, NULL);
>>
>> return VM_FAULT_FALLBACK;
>> @@ -4058,6 +4058,8 @@ static int __handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
>> .flags = flags,
>> .pgoff = linear_page_index(vma, address),
>> .gfp_mask = __get_fault_gfp_mask(vma),
>> + .vma_flags = vma->vm_flags,
>> + .vma_page_prot = vma->vm_page_prot,
>> };
>> unsigned int dirty = flags & FAULT_FLAG_WRITE;
>> struct mm_struct *mm = vma->vm_mm;
>
> Don't you also need to do this?
In theory there is no risk there, because if the vma->vm_flags have changed in
our back, the locking of the pte will prevent concurrent update of the pte's
values.
So if a mprotect() call is occuring in parallel, once the vm_flags have been
touched, the pte needs to be modified and this requires the pte lock to be
held. So this will happen after we have revalidated the vma and locked the pte.
This being said, that sounds better to deal with the vmf->vma_flags when the
vmf structure is available so I'll apply the following.
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -694,9 +694,9 @@ void free_compound_page(struct page *page);
> * pte_mkwrite. But get_user_pages can cause write faults for mappings
> * that do not have writing enabled, when used by access_process_vm.
> */
> -static inline pte_t maybe_mkwrite(pte_t pte, struct vm_area_struct *vma)
> +static inline pte_t maybe_mkwrite(pte_t pte, unsigned long vma_flags)
> {
> - if (likely(vma->vm_flags & VM_WRITE))
> + if (likely(vma_flags & VM_WRITE))
> pte = pte_mkwrite(pte);
> return pte;
> }
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1195,8 +1195,8 @@ static int do_huge_pmd_wp_page_fallback(struct vm_fault *vmf, pmd_t orig_pmd,
>
> for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
> pte_t entry;
> - entry = mk_pte(pages[i], vma->vm_page_prot);
> - entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> + entry = mk_pte(pages[i], vmf->vma_page_prot);
> + entry = maybe_mkwrite(pte_mkdirty(entry), vmf->vma_flags);
> memcg = (void *)page_private(pages[i]);
> set_page_private(pages[i], 0);
> page_add_new_anon_rmap(pages[i], vmf->vma, haddr, false);
> @@ -2169,7 +2169,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
> entry = pte_swp_mksoft_dirty(entry);
> } else {
> entry = mk_pte(page + i, READ_ONCE(vma->vm_page_prot));
> - entry = maybe_mkwrite(entry, vma);
> + entry = maybe_mkwrite(entry, vma->vm_flags);
> if (!write)
> entry = pte_wrprotect(entry);
> if (!young)
> diff --git a/mm/memory.c b/mm/memory.c
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1826,7 +1826,7 @@ static int insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> out_mkwrite:
> if (mkwrite) {
> entry = pte_mkyoung(entry);
> - entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> + entry = maybe_mkwrite(pte_mkdirty(entry), vma->vm_flags);
> }
>
> set_pte_at(mm, addr, pte, entry);
> @@ -2472,7 +2472,7 @@ static inline void wp_page_reuse(struct vm_fault *vmf)
>
> flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte));
> entry = pte_mkyoung(vmf->orig_pte);
> - entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> + entry = maybe_mkwrite(pte_mkdirty(entry), vmf->vma_flags);
> if (ptep_set_access_flags(vma, vmf->address, vmf->pte, entry, 1))
> update_mmu_cache(vma, vmf->address, vmf->pte);
> pte_unmap_unlock(vmf->pte, vmf->ptl);
> @@ -2549,8 +2549,8 @@ static int wp_page_copy(struct vm_fault *vmf)
> inc_mm_counter_fast(mm, MM_ANONPAGES);
> }
> flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte));
> - entry = mk_pte(new_page, vma->vm_page_prot);
> - entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> + entry = mk_pte(new_page, vmf->vma_page_prot);
> + entry = maybe_mkwrite(pte_mkdirty(entry), vmf->vma_flags);
> /*
> * Clear the pte entry and flush it first, before updating the
> * pte with the new entry. This will avoid a race condition
> @@ -3069,7 +3069,7 @@ int do_swap_page(struct vm_fault *vmf)
> dec_mm_counter_fast(vma->vm_mm, MM_SWAPENTS);
> pte = mk_pte(page, vmf->vma_page_prot);
> if ((vmf->flags & FAULT_FLAG_WRITE) && reuse_swap_page(page, NULL)) {
> - pte = maybe_mkwrite(pte_mkdirty(pte), vma);
> + pte = maybe_mkwrite(pte_mkdirty(pte), vmf->vm_flags);
> vmf->flags &= ~FAULT_FLAG_WRITE;
> ret |= VM_FAULT_WRITE;
> exclusive = RMAP_EXCLUSIVE;
> @@ -3481,7 +3481,7 @@ int alloc_set_pte(struct vm_fault *vmf, struct mem_cgroup *memcg,
> flush_icache_page(vma, page);
> entry = mk_pte(page, vmf->vma_page_prot);
> if (write)
> - entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> + entry = maybe_mkwrite(pte_mkdirty(entry), vmf->vm_flags);
> /* copy-on-write page */
> if (write && !(vmf->vma_flags & VM_SHARED)) {
> inc_mm_counter_fast(vma->vm_mm, MM_ANONPAGES);
> diff --git a/mm/migrate.c b/mm/migrate.c
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -240,7 +240,7 @@ static bool remove_migration_pte(struct page *page, struct vm_area_struct *vma,
> */
> entry = pte_to_swp_entry(*pvmw.pte);
> if (is_write_migration_entry(entry))
> - pte = maybe_mkwrite(pte, vma);
> + pte = maybe_mkwrite(pte, vma->vm_flags);
>
> if (unlikely(is_zone_device_page(new))) {
> if (is_device_private_page(new)) {
>
^ permalink raw reply
* [PATCH, RESEND, pci, v2] pci: Delete PCI disabling informational messages
From: Desnes A. Nunes do Rosario @ 2018-04-04 15:10 UTC (permalink / raw)
To: linux-kernel, linux-pci, linuxppc-dev; +Cc: bhelgaas
The disabling informational messages on the PCI subsystem should be deleted
since they do not represent any real value for the system logs.
These messages are either not presented, or presented for all PCI devices
(e.g., powerpc now realigns all PCI devices to its page size). Thus, they
are flooding system logs and can be interpreted as a false positive for
total PCI failure on the system.
[root@system user]# dmesg | grep -i disabling
[ 0.692270] pci 0000:00:00.0: Disabling memory decoding and releasing memory resources
[ 0.692324] pci 0000:00:00.0: disabling bridge mem windows
[ 0.729134] pci 0001:00:00.0: Disabling memory decoding and releasing memory resources
[ 0.737352] pci 0001:00:00.0: disabling bridge mem windows
[ 0.776295] pci 0002:00:00.0: Disabling memory decoding and releasing memory resources
[ 0.784509] pci 0002:00:00.0: disabling bridge mem windows
... and goes on for all PCI devices on the system ...
Fixes: 38274637699 ("powerpc/powernv: Override pcibios_default_alignment() to force PCI devices to be page aligned")
Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com>
---
drivers/pci/pci.c | 1 -
drivers/pci/setup-res.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8c71d1a66cdd..1563ce1ee091 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5505,7 +5505,6 @@ void pci_reassigndev_resource_alignment(struct pci_dev *dev)
return;
}
- pci_info(dev, "Disabling memory decoding and releasing memory resources\n");
pci_read_config_word(dev, PCI_COMMAND, &command);
command &= ~PCI_COMMAND_MEMORY;
pci_write_config_word(dev, PCI_COMMAND, command);
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 369d48d6c6f1..6bd35e8e7cde 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -172,8 +172,6 @@ EXPORT_SYMBOL(pci_claim_resource);
void pci_disable_bridge_window(struct pci_dev *dev)
{
- pci_info(dev, "disabling bridge mem windows\n");
-
/* MMIO Base/Limit */
pci_write_config_dword(dev, PCI_MEMORY_BASE, 0x0000fff0);
--
2.14.3
^ permalink raw reply related
* Re: powerpc/hw_breakpoint: Only disable hw breakpoint if cpu supports it
From: Michael Ellerman @ 2018-04-04 14:39 UTC (permalink / raw)
To: Naveen N. Rao; +Cc: linuxppc-dev
In-Reply-To: <20180404104116.27819-1-naveen.n.rao@linux.vnet.ibm.com>
On Wed, 2018-04-04 at 10:41:16 UTC, "Naveen N. Rao" wrote:
> We get the below warning if we try to use kexec on P9:
> kexec_core: Starting new kernel
> WARNING: CPU: 0 PID: 1223 at arch/powerpc/kernel/process.c:826 __set_breakpoint+0xb4/0x140
> [snip]
> NIP [c00000000001bf44] __set_breakpoint+0xb4/0x140
> LR [c000000000061268] kexec_prepare_cpus_wait+0x58/0x150
> Call Trace:
> [c0000000ee70fad0] [c0000000ee70fb20] 0xc0000000ee70fb20 (unreliable)
> [c0000000ee70faf0] [c0000000ee70fb20] 0xc0000000ee70fb20
> [c0000000ee70fbb0] [c000000000061884] default_machine_kexec+0x234/0x2c0
> [c0000000ee70fc40] [c0000000000605c4] machine_kexec+0x84/0x90
> [c0000000ee70fc70] [c000000000206548] kernel_kexec+0xd8/0xe0
> [c0000000ee70fce0] [c000000000169e74] SyS_reboot+0x214/0x2c0
> [c0000000ee70fe30] [c00000000000bd60] system_call+0x58/0x6c
>
> This happens since we are trying to clear hw breakpoint on POWER9, though
> we don't have CPU_FTR_DAWR enabled. Guard __set_breakpoint() within
> hw_breakpoint_disable() with ppc_breakpoint_available() to address this.
>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/5d6a03ebc88f82b0b0adcec24eabb9
cheers
^ permalink raw reply
* Re: [v2] cxl: Fix possible deadlock when processing page faults from cxllib
From: Michael Ellerman @ 2018-04-04 14:39 UTC (permalink / raw)
To: Frederic Barrat, linuxppc-dev
Cc: ldufour, clombard, andrew.donnellan, vaibhav
In-Reply-To: <20180403135402.30374-1-fbarrat@linux.vnet.ibm.com>
On Tue, 2018-04-03 at 13:54:02 UTC, Frederic Barrat wrote:
> cxllib_handle_fault() is called by an external driver when it needs to
> have the host resolve page faults for a buffer. The buffer can cover
> several pages and VMAs. The function iterates over all the pages used
> by the buffer, based on the page size of the VMA.
>
> To ensure some stability while processing the faults, the thread T1
> grabs the mm->mmap_sem semaphore with read access (R1). However, when
> processing a page fault for a single page, one of the underlying
> functions, copro_handle_mm_fault(), also grabs the same semaphore with
> read access (R2). So the thread T1 takes the semaphore twice.
>
> If another thread T2 tries to access the semaphore in write mode W1
> (say, because it wants to allocate memory and calls 'brk'), then that
> thread T2 will have to wait because there's a reader (R1). If the
> thread T1 is processing a new page at that time, it won't get an
> automatic grant at R2, because there's now a writer thread
> waiting (T2). And we have a deadlock.
>
> The timeline is:
> 1. thread T1 owns the semaphore with read access R1
> 2. thread T2 requests write access W1 and waits
> 3. thread T1 requests read access R2 and waits
>
> The fix is for the thread T1 to release the semaphore R1 once it got
> the information it needs from the current VMA. The address space/VMAs
> could evolve while T1 iterates over the full buffer, but in the
> unlikely case where T1 misses a page, the external driver will raise a
> new page fault when retrying the memory access.
>
> Fixes: 3ced8d730063 ("cxl: Export library to support IBM XSL")
> Cc: stable@vger.kernel.org # 4.13+
> Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ad7b4e8022b9864c075fe71e1328b1
cheers
^ permalink raw reply
* Re: [v2,1/3] powerpc: use NMI IPI for smp_send_stop
From: Michael Ellerman @ 2018-04-04 14:39 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Vasant Hegde, Nicholas Piggin
In-Reply-To: <20180401103615.15454-2-npiggin@gmail.com>
On Sun, 2018-04-01 at 10:36:13 UTC, Nicholas Piggin wrote:
> Use the NMI IPI rather than smp_call_function for smp_send_stop.
> Have stopped CPUs hard disable interrupts rather than just soft
> disable.
>
> This function is used in crash/panic/shutdown paths to bring other
> CPUs down as quickly and reliably as possible, and minimizing their
> potential to cause trouble.
>
> Avoiding the Linux smp_call_function infrastructure and (if supported)
> using true NMI IPIs makes this more robust.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6bed3237624e3faad1592543952907
cheers
^ permalink raw reply
* Re: [v3, 3/3] powerpc/64s/idle: POWER9 ESL=0 stop avoid save/restore overhead
From: Michael Ellerman @ 2018-04-04 14:39 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Gautham R . Shenoy, Nicholas Piggin
In-Reply-To: <20180401054855.17864-4-npiggin@gmail.com>
On Sun, 2018-04-01 at 05:48:55 UTC, Nicholas Piggin wrote:
> When stop is executed with EC=ESL=0, it appears to execute like a
> normal instruction (resuming from NIP when woken by interrupt). So all
> the save/restore handling can be avoided completely. In particular NV
> GPRs do not have to be saved, and MSR does not have to be switched
> back to kernel MSR.
>
> So move the test for EC=ESL=0 sleep states out to power9_idle_stop,
> and return directly to the caller after stop in that case.
>
> This improves performance for ping-pong benchmark with the stop0_lite
> idle state by 2.54% for 2 threads in the same core, and 2.57% for
> different cores. Performance increase with HV_POSSIBLE defined will be
> improved further by avoiding the hwsync.
>
> Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
> Cc: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> Cc: Paul Mackerras <paulus@ozlabs.org>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b9ee31e100e73075431faaf7af2ee0
cheers
^ permalink raw reply
* Re: powerpc/powernv: Fix SMT4 forcing idle code
From: Michael Ellerman @ 2018-04-04 14:39 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180401053813.17405-1-npiggin@gmail.com>
On Sun, 2018-04-01 at 05:38:13 UTC, Nicholas Piggin wrote:
> PSSCR value is not stored to PACA_REQ_PSSCR in case the CPU does
> not have the XER[SO] bug.
>
> Fix this by storing up-front, outside the workaround code. The
> initial test is not required because it is a slow path.
>
> The workaround is made to depend on CONFIG_KVM_BOOK3S_HV_POSSIBLE, to
> match pnv_power9_force_smt4_catch() where it is used.
>
> Fixes: 7672691a08 ("powerpc/powernv: Provide a way to force a core into SMT4 mode")
> Cc: Paul Mackerras <paulus@ozlabs.org>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a2b5e056b75ee6ef0777817644a456
cheers
^ permalink raw reply
* Re: [1/2] powerpc/mm/radix: Parse disable_radix commandline correctly.
From: Michael Ellerman @ 2018-04-04 14:39 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180330120902.28798-1-aneesh.kumar@linux.ibm.com>
On Fri, 2018-03-30 at 12:09:01 UTC, "Aneesh Kumar K.V" wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> kernel parameter disable_radix takes different options
> disable_radix=yes|no|1|0 or just disable_radix. When using the later format
> we get below error.
>
> `Malformed early option 'disable_radix'`
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/cec4e9b28ffbcb9ce04b9e33946c50
cheers
^ permalink raw reply
* Re: [V3] powerpc/mm/hugetlb: initialize the pagetable cache correctly for hugetlb
From: Michael Ellerman @ 2018-04-04 14:39 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180330120408.25036-1-aneesh.kumar@linux.ibm.com>
On Fri, 2018-03-30 at 12:04:08 UTC, "Aneesh Kumar K.V" wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> With 64k page size, we have hugetlb pte entries at the pmd and pud level for
> book3s64. We don't need to create a separate page table cache for that. With 4k
> we need to make sure hugepd page table cache for 16M is placed at PUD level
> and 16G at the PGD level.
>
> Simplify all these by not using HUGEPD_PD_SHIFT which is confusing for book3s64.
>
> Without this patch, with 64k page size we create pagetable caches with shift
> value 10 and 7 which are not used at all.
>
> Fixes: 419df06eea5b ("powerpc: Reduce the PTE_INDEX_SIZE")
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6fa504835d6969144b2bd3699684dd
cheers
^ permalink raw reply
* Re: [V2] powerpc/mm/radix: Update pte fragment count from 16 to 256 on radix
From: Michael Ellerman @ 2018-04-04 14:39 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180322084350.21249-1-aneesh.kumar@linux.vnet.ibm.com>
On Thu, 2018-03-22 at 08:43:50 UTC, "Aneesh Kumar K.V" wrote:
> Right now we use only 4K out of the 64k page allocated for the level 4 page
> table. W.r.t the performance impact due to lock contention, with ebizzy
>
> 256 threads:
> without patch (10 runs of ./ebizzy -m -n 1000 -s 131072 -S 100)
> median = 15678.5
> stdev = 42.1209
>
> with patch:
> median = 15354
> stdev = 194.743
>
> This is with THP disabled. With THP enabled the impact of the patch will be less.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/fb4e5dbd44564077fa0267a59b4596
cheers
^ permalink raw reply
* Re: [2/2] powerpc/mm/keys: Update documentation in key fault handling
From: Michael Ellerman @ 2018-04-04 14:39 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus, linuxram; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180307133645.29290-2-aneesh.kumar@linux.vnet.ibm.com>
On Wed, 2018-03-07 at 13:36:45 UTC, "Aneesh Kumar K.V" wrote:
> No functionality change in this patch. Adds more code comments. We also remove
> an unnecessary pkey check after we check for pkey error in this patch.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f2ed480fa4d7f95b190279722690df
cheers
^ permalink raw reply
* Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings
From: Dan Williams @ 2018-04-04 14:21 UTC (permalink / raw)
To: Oliver; +Cc: Balbir Singh, Device Tree, linuxppc-dev, linux-nvdimm
In-Reply-To: <CAOSf1CGdKU4zQQauqo3UoNvKnKDMHteAEtsMWVtTG7T01csMbg@mail.gmail.com>
On Wed, Apr 4, 2018 at 7:04 AM, Oliver <oohall@gmail.com> wrote:
> On Wed, Apr 4, 2018 at 10:07 PM, Balbir Singh <bsingharora@gmail.com> wrote:
>> On Tue, 3 Apr 2018 10:37:51 -0700
>> Dan Williams <dan.j.williams@intel.com> wrote:
>>
>>> On Tue, Apr 3, 2018 at 7:24 AM, Oliver O'Halloran <oohall@gmail.com> wrote:
>>> > Add device-tree binding documentation for the nvdimm region driver.
>>> >
>>> > Cc: devicetree@vger.kernel.org
>>> > Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
>>> > ---
>>> > v2: Changed name from nvdimm-region to pmem-region.
>>> > Cleaned up the example binding and fixed the overlapping regions.
>>> > Added support for multiple regions in a single reg.
>>> > ---
>>> > .../devicetree/bindings/pmem/pmem-region.txt | 80 ++++++++++++++++++++++
>>> > MAINTAINERS | 1 +
>>> > 2 files changed, 81 insertions(+)
>>> > create mode 100644 Documentation/devicetree/bindings/pmem/pmem-region.txt
>>>
>>> Device-tree folks, does this look, ok?
>>>
>>> Oliver, is there any concept of a management interface to the
>>> device(s) backing these regions? libnvdimm calls these "nmem" devices
>>> and support operations like health status and namespace label
>>> management.
>
> It's something I'm planning on implementing as soon as someone gives
> me some hardware that isn't hacked up lab crap. I'm posting this
> version with just regions since people have been asking for something
> in upstream even if it's not fully featured.
>
> Grumbling aside, the plan is to have separate drivers for the DIMM
> type. Discovering DIMM devices happens via the normal discovery
> mechanisms (e.g. an NVDIMM supporting the JEDEC interface is an I2C
> device) and when binding to a specific DIMM device it registers a DIMM
> descriptor structure and a ndctl implementation for that DIMM type
> with of_pmem. When of_pmem binds to a region it can plug everything
> into the region specific bus. There's a few details to work out, but I
> think it's a reasonable approach.
Yeah, that sounds reasonable. It would mean that your management
interface would need to understand that nmems on different buses could
potentially move to another bus after a reconfiguration, but that's
not too much different than the ACPI case where nmems can join and
leave regions after a reset / reconfig.
>> We would need a way to have nmem and pmem-regions find each other. Since we
>> don't have the ACPI abstractions, the nmem region would need to add the
>> ability for a driver to have a phandle to the interleaving and nmem properties.
>>
>> I guess that would be a separate driver, that would manage the nmem devices
>> and there would be a way to relate the pmem and nmems. Oliver?
>
> Yes, that's the plan.
So Balbir, is that enough for an Acked-by for this device-tree proposal?
^ permalink raw reply
* Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings
From: Oliver @ 2018-04-04 14:04 UTC (permalink / raw)
To: Balbir Singh; +Cc: Dan Williams, Device Tree, linuxppc-dev, linux-nvdimm
In-Reply-To: <20180404220750.0436bbe1@gmail.com>
On Wed, Apr 4, 2018 at 10:07 PM, Balbir Singh <bsingharora@gmail.com> wrote:
> On Tue, 3 Apr 2018 10:37:51 -0700
> Dan Williams <dan.j.williams@intel.com> wrote:
>
>> On Tue, Apr 3, 2018 at 7:24 AM, Oliver O'Halloran <oohall@gmail.com> wrote:
>> > Add device-tree binding documentation for the nvdimm region driver.
>> >
>> > Cc: devicetree@vger.kernel.org
>> > Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
>> > ---
>> > v2: Changed name from nvdimm-region to pmem-region.
>> > Cleaned up the example binding and fixed the overlapping regions.
>> > Added support for multiple regions in a single reg.
>> > ---
>> > .../devicetree/bindings/pmem/pmem-region.txt | 80 ++++++++++++++++++++++
>> > MAINTAINERS | 1 +
>> > 2 files changed, 81 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/pmem/pmem-region.txt
>>
>> Device-tree folks, does this look, ok?
>>
>> Oliver, is there any concept of a management interface to the
>> device(s) backing these regions? libnvdimm calls these "nmem" devices
>> and support operations like health status and namespace label
>> management.
It's something I'm planning on implementing as soon as someone gives
me some hardware that isn't hacked up lab crap. I'm posting this
version with just regions since people have been asking for something
in upstream even if it's not fully featured.
Grumbling aside, the plan is to have separate drivers for the DIMM
type. Discovering DIMM devices happens via the normal discovery
mechanisms (e.g. an NVDIMM supporting the JEDEC interface is an I2C
device) and when binding to a specific DIMM device it registers a DIMM
descriptor structure and a ndctl implementation for that DIMM type
with of_pmem. When of_pmem binds to a region it can plug everything
into the region specific bus. There's a few details to work out, but I
think it's a reasonable approach.
> We would need a way to have nmem and pmem-regions find each other. Since we
> don't have the ACPI abstractions, the nmem region would need to add the
> ability for a driver to have a phandle to the interleaving and nmem properties.
>
> I guess that would be a separate driver, that would manage the nmem devices
> and there would be a way to relate the pmem and nmems. Oliver?
Yes, that's the plan.
^ permalink raw reply
* Re: [PATCH] cxl: Fix possible deadlock when processing page faults from cxllib
From: Frederic Barrat @ 2018-04-04 10:58 UTC (permalink / raw)
To: Aneesh Kumar K.V, Frederic Barrat, linuxppc-dev, mpe
Cc: ldufour, clombard, andrew.donnellan, vaibhav
In-Reply-To: <8e099a01-ba11-d26f-07ab-bf0fa6e387c1@linux.ibm.com>
Le 03/04/2018 à 17:31, Aneesh Kumar K.V a écrit :
> On 04/03/2018 08:10 PM, Aneesh Kumar K.V wrote:
>> On 04/03/2018 03:13 PM, Frederic Barrat wrote:
>>> cxllib_handle_fault() is called by an external driver when it needs to
>>> have the host process page faults for a buffer which may cover several
>>> pages. Currently the function holds the mm->mmap_sem semaphore with
>>> read access while iterating over the buffer, since it could spawn
>>> several VMAs. When calling a lower-level function to handle the page
>>> fault for a single page, the semaphore is accessed again in read
>>> mode. That is wrong and can lead to deadlocks if a writer tries to
>>> sneak in while a buffer of several pages is being processed.
>>>
>>> The fix is to release the semaphore once cxllib_handle_fault() got the
>>> information it needs from the current vma. The address space/VMAs
>>> could evolve while we iterate over the full buffer, but in the
>>> unlikely case where we miss a page, the driver will raise a new page
>>> fault when retrying.
>>>
>>> Fixes: 3ced8d730063 ("cxl: Export library to support IBM XSL")
>>> Cc: stable@vger.kernel.org # 4.13+
>>> Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
>>> ---
>>> drivers/misc/cxl/cxllib.c | 85
>>> ++++++++++++++++++++++++++++++-----------------
>>> 1 file changed, 55 insertions(+), 30 deletions(-)
>>>
>>> diff --git a/drivers/misc/cxl/cxllib.c b/drivers/misc/cxl/cxllib.c
>>> index 30ccba436b3b..55cd35d1a9cc 100644
>>> --- a/drivers/misc/cxl/cxllib.c
>>> +++ b/drivers/misc/cxl/cxllib.c
>>> @@ -208,49 +208,74 @@ int cxllib_get_PE_attributes(struct task_struct
>>> *task,
>>> }
>>> EXPORT_SYMBOL_GPL(cxllib_get_PE_attributes);
>>> -int cxllib_handle_fault(struct mm_struct *mm, u64 addr, u64 size,
>>> u64 flags)
>>> +static int get_vma_info(struct mm_struct *mm, u64 addr,
>>> + u64 *vma_start, u64 *vma_end,
>>> + unsigned long *page_size)
>>> {
>>> - int rc;
>>> - u64 dar;
>>> struct vm_area_struct *vma = NULL;
>>> - unsigned long page_size;
>>> -
>>> - if (mm == NULL)
>>> - return -EFAULT;
>>> + int rc = 0;
>>> down_read(&mm->mmap_sem);
>>> vma = find_vma(mm, addr);
>>> if (!vma) {
>>> - pr_err("Can't find vma for addr %016llx\n", addr);
>>> rc = -EFAULT;
>>> goto out;
>>> }
>>> - /* get the size of the pages allocated */
>>> - page_size = vma_kernel_pagesize(vma);
>>> -
>>> - for (dar = (addr & ~(page_size - 1)); dar < (addr + size); dar
>>> += page_size) {
>>> - if (dar < vma->vm_start || dar >= vma->vm_end) {
>>> - vma = find_vma(mm, addr);
>>> - if (!vma) {
>>> - pr_err("Can't find vma for addr %016llx\n", addr);
>>> - rc = -EFAULT;
>>> - goto out;
>>> - }
>>> - /* get the size of the pages allocated */
>>> - page_size = vma_kernel_pagesize(vma);
>>> + *page_size = vma_kernel_pagesize(vma);
>>> + *vma_start = vma->vm_start;
>>> + *vma_end = vma->vm_end;
>>> +out:
>>> + up_read(&mm->mmap_sem);
>>> + return rc;
>>> +}
>>> +
>>> +int cxllib_handle_fault(struct mm_struct *mm, u64 addr, u64 size,
>>> u64 flags)
>>> +{
>>> + int rc;
>>> + u64 dar, vma_start, vma_end;
>>> + unsigned long page_size;
>>> +
>>> + if (mm == NULL)
>>> + return -EFAULT;
>>> +
>>> + /*
>>> + * The buffer we have to process can extend over several pages
>>> + * and may also cover several VMAs.
>>> + * We iterate over all the pages. The page size could vary
>>> + * between VMAs.
>>> + */
>>> + rc = get_vma_info(mm, addr, &vma_start, &vma_end, &page_size);
>>> + if (rc)
>>> + return rc;
>>> +
>>> + for (dar = (addr & ~(page_size - 1)); dar < (addr + size);
>>> + dar += page_size) {
>>> + if (dar < vma_start || dar >= vma_end) {
>>
>>
>> IIUC, we are fetching the vma to get just the page_size with which it
>> is mapped? Can't we iterate with PAGE_SIZE? Considering hugetlb page
>> size will be larger than PAGE_SIZE, we might call into
>> cxl_handle_mm_fault multiple times for a hugetlb page. Does that cause
>> any issue? Also can cxl be used with hugetlb mappings?
>>
> Can you also try to use a helper like below. That will clarify the need
> of find_vma there.
>
> static int __cxllib_handle_fault(struct mm_struct *mm, unsigned long
> start, unsigned long end,
> unsigned long mapping_psize, u64 flags)
> {
> int rc;
> unsigned long dar;
>
> for (dar = start; dar < end; dar += mapping_psize) {
> rc = cxl_handle_mm_fault(mm, flags, dar);
> if (rc) {
> rc = -EFAULT;
> goto out;
> }
> }
> rc = 0;
> out:
> return rc;
> }
I'm struggling to make good use of it. I see your point, it makes
touching all the pages for a given VMA easy (same page size).
But I'm given a buffer, which can span several VMAs, and we can have a
varying page size. So I now need an outside loop iterating over all the
VMAs and call the helper for a subset of the VMA. IMHO, it's not making
the code any easier, i.e what I gain in the helper is lost in the
outside VMA loop.
The current code, with a single loop and a varying increment based on
the page size, doesn't look that bad to me.
Fred
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/cpu: raise DEVICE_ADD/REMOVE msg to usrspace
From: Hari Bathini @ 2018-04-04 13:33 UTC (permalink / raw)
To: Pingfan Liu, linuxppc-dev
In-Reply-To: <1522372657-27490-1-git-send-email-kernelfans@gmail.com>
On Friday 30 March 2018 06:47 AM, Pingfan Liu wrote:
> Some user space tools such as kexec-tools resort to the event
> add/remove to decide whether rebuilding dtb or not.
> So if a new core added and a crash happens on one of its thread,
> then kexec fails to bring up the 2nd kernel since lacking the info
> of boot-cpu-hwid in dtb. This patch uses the interface
> register_/unregister_cpu to fix the problem
>
> Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
> Reported-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Thanks for fixing this, Pingfan.
Looks good to me. I now see add/remove uevents for CPUs.
For the series...
Reviewed-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/smp.h | 1 +
> arch/powerpc/kernel/sysfs.c | 26 ++++++++++++++------------
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 3 ++-
> 3 files changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
> index fac963e..3ef730d 100644
> --- a/arch/powerpc/include/asm/smp.h
> +++ b/arch/powerpc/include/asm/smp.h
> @@ -35,6 +35,7 @@ extern int spinning_secondaries;
> extern void cpu_die(void);
> extern int cpu_to_chip_id(int cpu);
>
> +DECLARE_PER_CPU(struct cpu, cpu_devices);
> #ifdef CONFIG_SMP
>
> struct smp_ops_t {
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index 04d0bbd..dbbcc96 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -26,7 +26,7 @@
> #include <asm/lppaca.h>
> #endif
>
> -static DEFINE_PER_CPU(struct cpu, cpu_devices);
> +DEFINE_PER_CPU(struct cpu, cpu_devices);
>
> /*
> * SMT snooze delay stuff, 64-bit only for now
> @@ -716,6 +716,16 @@ static struct device_attribute pa6t_attrs[] = {
> #endif /* HAS_PPC_PMC_PA6T */
> #endif /* HAS_PPC_PMC_CLASSIC */
>
> +/* Only valid if CPU is present. */
> +static ssize_t show_physical_id(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct cpu *cpu = container_of(dev, struct cpu, dev);
> +
> + return sprintf(buf, "%d\n", get_hard_smp_processor_id(cpu->dev.id));
> +}
> +static DEVICE_ATTR(physical_id, 0444, show_physical_id, NULL);
> +
> static int register_cpu_online(unsigned int cpu)
> {
> struct cpu *c = &per_cpu(cpu_devices, cpu);
> @@ -723,6 +733,8 @@ static int register_cpu_online(unsigned int cpu)
> struct device_attribute *attrs, *pmc_attrs;
> int i, nattrs;
>
> + device_create_file(&c->dev, &dev_attr_physical_id);
> +
> /* For cpus present at boot a reference was already grabbed in register_cpu() */
> if (!s->of_node)
> s->of_node = of_get_cpu_node(cpu, NULL);
> @@ -816,6 +828,7 @@ static int unregister_cpu_online(unsigned int cpu)
>
> BUG_ON(!c->hotpluggable);
>
> + device_remove_file(s, &dev_attr_physical_id);
> #ifdef CONFIG_PPC64
> if (cpu_has_feature(CPU_FTR_SMT))
> device_remove_file(s, &dev_attr_smt_snooze_delay);
> @@ -1017,16 +1030,6 @@ static void register_nodes(void)
>
> #endif
>
> -/* Only valid if CPU is present. */
> -static ssize_t show_physical_id(struct device *dev,
> - struct device_attribute *attr, char *buf)
> -{
> - struct cpu *cpu = container_of(dev, struct cpu, dev);
> -
> - return sprintf(buf, "%d\n", get_hard_smp_processor_id(cpu->dev.id));
> -}
> -static DEVICE_ATTR(physical_id, 0444, show_physical_id, NULL);
> -
> static int __init topology_init(void)
> {
> int cpu, r;
> @@ -1049,7 +1052,6 @@ static int __init topology_init(void)
> if (cpu_online(cpu) || c->hotpluggable) {
> register_cpu(c, cpu);
>
> - device_create_file(&c->dev, &dev_attr_physical_id);
> }
> }
> r = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "powerpc/topology:online",
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index 652d3e96..697dfb7 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -367,6 +367,7 @@ static int dlpar_online_cpu(struct device_node *dn)
> cpu_maps_update_done();
> timed_topology_update(1);
> find_and_online_cpu_nid(cpu);
> + register_cpu(&per_cpu(cpu_devices, cpu), cpu);
> rc = device_online(get_cpu_device(cpu));
> if (rc)
> goto out;
> @@ -541,6 +542,7 @@ static int dlpar_offline_cpu(struct device_node *dn)
> rc = device_offline(get_cpu_device(cpu));
> if (rc)
> goto out;
> + unregister_cpu(container_of(get_cpu_device(cpu), struct cpu, dev));
> cpu_maps_update_begin();
> break;
>
> @@ -599,7 +601,6 @@ static ssize_t dlpar_cpu_remove(struct device_node *dn, u32 drc_index)
>
> return saved_rc;
> }
> -
> pr_debug("Successfully removed CPU, drc index: %x\n", drc_index);
> return 0;
> }
^ permalink raw reply
* Re: [1/3] powerpc/64s/idle: POWER9 implement a separate idle stop function for hotplug
From: Michael Ellerman @ 2018-04-04 12:52 UTC (permalink / raw)
To: Nicholas Piggin, Michael Ellerman; +Cc: linuxppc-dev, Gautham R . Shenoy
In-Reply-To: <20180404031352.2281c7a1@roar.ozlabs.ibm.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> On Wed, 4 Apr 2018 02:03:18 +1000 (AEST)
> Michael Ellerman <patch-notifications@ellerman.id.au> wrote:
>> On Fri, 2017-11-17 at 14:08:05 UTC, Nicholas Piggin wrote:
>> > Implement a new function to invoke stop, power9_offline_stop, which is
>> > like power9_idle_stop but used by the cpu hotplug code.
>> >
>> > Move KVM secondary state manipulation code to the offline case.
>> >
>> > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> > Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
>>
>> Applied to powerpc next, thanks.
>>
>> https://git.kernel.org/powerpc/c/3d4fbffdd703d2b968db443911f214
>
> I sent out a new series for this which is rebased and a bit cleaner.
> I probably wasn't clear enough about the change, sorry.
No that's OK, I just already had the previous series applied (partially)
in my testing tree and didn't see the new series in time to back it out.
> This patch will need to be adjusted for the force SMT4 change. The
> end result should look like this,
>
> https://patchwork.ozlabs.org/patch/893948/
Thanks. I did a patch to get everything in sync, and confirmed the
result is the same as applying your new series.
cheers
^ permalink raw reply
* Re: [RFC 1/2] powerpc/swiotlb: Dont free up allocated SWIOTLB slab on POWER
From: Michael Ellerman @ 2018-04-04 12:48 UTC (permalink / raw)
To: Anshuman Khandual, linuxppc-dev
In-Reply-To: <20180404030301.25019-1-khandual@linux.vnet.ibm.com>
Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:
> Even though SWIOTLB slab gets allocated and initialized on powerpc with
> swiotlb_init() called during mem_init(), it gets released away again on
> POWER platform because 'ppc_swiotlb_enable' never gets set. The function
> swiotlb_detect_4g() checks for 4GB memory and then sets the variable
> 'ppc_swiotlb_enable' which prevents freeing up the SWIOTLB slab. Lets
> make POWER platform call swiotlb_detect_4g() during setup_arch() which
> will keep the SWIOTLB slab through out the runtime.
>
> A previous commit cf5621032f ("powerpc/64: Limit ZONE_DMA32 to 4GiB in
> swiotlb_detect_4g()") enforced 4GB limit on ZONE_DMA32 which is is not
> applicable on POWER (CONFIG_PPC_BOOK3S_64) platform. Lets remove this
> unnecessary restriction.
You're using "POWER" to mean Book3S 64-bit, but "POWER" is something
else (the ISA for POWER1/POWER2).
So please just say "Book3S 64-bit" or talk about a specific CPU, eg.
Power9.
> After the patch, SWIOTLB slab does not get released.
>
> [0.410992] software IO TLB [mem 0xfbff0000-0xffff0000] (64MB) mapped
> at [00000000767f6cb3-000000004a10114f]
But we don't want SWIOTLB on any existing Book3S 64-bit platforms, so
leaving it enabled is just wasting memory.
> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> index d73ec518ef80..c4db844e0b0d 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -944,6 +944,7 @@ void __init setup_arch(char **cmdline_p)
> /* Initialize the MMU context management stuff. */
> mmu_context_init();
>
> + swiotlb_detect_4g();
You shouldn't be calling this, your use case has nothing to do with 4GB.
Instead when you detect that you're running under the ultravisor then
you should set ppc_swiotlb_enable = 1.
cheers
^ permalink raw reply
* Re: [RESEND v2 4/4] powerpc/powernv: Create platform devs for nvdimm buses
From: Balbir Singh @ 2018-04-04 12:20 UTC (permalink / raw)
To: Oliver O'Halloran; +Cc: linuxppc-dev, linux-nvdimm
In-Reply-To: <20180403142415.30083-4-oohall@gmail.com>
On Wed, 4 Apr 2018 00:24:15 +1000
Oliver O'Halloran <oohall@gmail.com> wrote:
> Scan the devicetree for an nvdimm-bus compatible and create
> a platform device for them.
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> ---
Acked-by: Balbir Singh <bsingharora@gmail.com>
^ 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