[PATCH 23/23] xtensa: add pte_unmap() to balance pte_offset_map()
To keep balance in future, remember to pte_unmap() after a successful
pte_offset_map(). And (might as well) pretend that get_pte_for_vaddr()
really needed a map there, to read the pteval before "unmapping".
Signed-off-by: Hugh Dickins
---
arch/xtensa/mm/tlb.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/xtensa/mm/tlb.c b/arch/xtensa/mm/tlb.c
index 27a477dae232..0a11fc5f185b 100644
--- a/arch/xtensa/mm/tlb.c
+++ b/arch/xtensa/mm/tlb.c
@@ -179,6 +179,7 @@ static unsigned get_pte_for_vaddr(unsigned vaddr)
pud_t *pud;
pmd_t *pmd;
pte_t *pte;
+ unsigned int pteval;
if (!mm)
mm = task->active_mm;
@@ -197,7 +198,9 @@ static unsigned get_pte_for_vaddr(unsigned vaddr)
pte = pte_offset_map(pmd, vaddr);
if (!pte)
return 0;
- return pte_val(*pte);
+ pteval = pte_val(*pte);
+ pte_unmap(pte);
+ return pteval;
}
enum {
--
2.35.3
[PATCH 22/23] x86: sme_populate_pgd() use pte_offset_kernel()
sme_populate_pgd() is an __init function for sme_encrypt_kernel(): it should use pte_offset_kernel() instead of pte_offset_map(), to avoid the question of whether a pte_unmap() will be needed to balance. Signed-off-by: Hugh Dickins --- arch/x86/mm/mem_encrypt_identity.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c index c6efcf559d88..a1ab542bdfd6 100644 --- a/arch/x86/mm/mem_encrypt_identity.c +++ b/arch/x86/mm/mem_encrypt_identity.c @@ -188,7 +188,7 @@ static void __init sme_populate_pgd(struct sme_populate_pgd_data *ppd) if (pmd_large(*pmd)) return; - pte = pte_offset_map(pmd, ppd->vaddr); + pte = pte_offset_kernel(pmd, ppd->vaddr); if (pte_none(*pte)) set_pte(pte, __pte(ppd->paddr | ppd->pte_flags)); } -- 2.35.3
[PATCH 21/23] x86: Allow get_locked_pte() to fail
In rare transient cases, not yet made possible, pte_offset_map() and
pte_offset_map_lock() may not find a page table: handle appropriately.
Signed-off-by: Hugh Dickins
---
arch/x86/kernel/ldt.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ldt.c b/arch/x86/kernel/ldt.c
index 525876e7b9f4..eb844549cd83 100644
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -367,8 +367,10 @@ static void unmap_ldt_struct(struct mm_struct *mm, struct
ldt_struct *ldt)
va = (unsigned long)ldt_slot_va(ldt->slot) + offset;
ptep = get_locked_pte(mm, va, );
- pte_clear(mm, va, ptep);
- pte_unmap_unlock(ptep, ptl);
+ if (ptep) {
+ pte_clear(mm, va, ptep);
+ pte_unmap_unlock(ptep, ptl);
+ }
}
va = (unsigned long)ldt_slot_va(ldt->slot);
--
2.35.3
[PATCH 20/23] sparc: iounit and iommu use pte_offset_kernel()
iounit_alloc() and sbus_iommu_alloc() are working from pmd_off_k(), so should use pte_offset_kernel() instead of pte_offset_map(), to avoid the question of whether a pte_unmap() will be needed to balance. Signed-off-by: Hugh Dickins --- arch/sparc/mm/io-unit.c | 2 +- arch/sparc/mm/iommu.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/sparc/mm/io-unit.c b/arch/sparc/mm/io-unit.c index bf3e6d2fe5d9..133dd42570d6 100644 --- a/arch/sparc/mm/io-unit.c +++ b/arch/sparc/mm/io-unit.c @@ -244,7 +244,7 @@ static void *iounit_alloc(struct device *dev, size_t len, long i; pmdp = pmd_off_k(addr); - ptep = pte_offset_map(pmdp, addr); + ptep = pte_offset_kernel(pmdp, addr); set_pte(ptep, mk_pte(virt_to_page(page), dvma_prot)); diff --git a/arch/sparc/mm/iommu.c b/arch/sparc/mm/iommu.c index 9e3f6933ca13..3a6caef68348 100644 --- a/arch/sparc/mm/iommu.c +++ b/arch/sparc/mm/iommu.c @@ -358,7 +358,7 @@ static void *sbus_iommu_alloc(struct device *dev, size_t len, __flush_page_to_ram(page); pmdp = pmd_off_k(addr); - ptep = pte_offset_map(pmdp, addr); + ptep = pte_offset_kernel(pmdp, addr); set_pte(ptep, mk_pte(virt_to_page(page), dvma_prot)); } -- 2.35.3
[PATCH 19/23] sparc: allow pte_offset_map() to fail
In rare transient cases, not yet made possible, pte_offset_map() and
pte_offset_map_lock() may not find a page table: handle appropriately.
Signed-off-by: Hugh Dickins
---
arch/sparc/kernel/signal32.c | 2 ++
arch/sparc/mm/fault_64.c | 3 +++
arch/sparc/mm/tlb.c | 2 ++
3 files changed, 7 insertions(+)
diff --git a/arch/sparc/kernel/signal32.c b/arch/sparc/kernel/signal32.c
index dad38960d1a8..ca450c7bc53f 100644
--- a/arch/sparc/kernel/signal32.c
+++ b/arch/sparc/kernel/signal32.c
@@ -328,6 +328,8 @@ static void flush_signal_insns(unsigned long address)
goto out_irqs_on;
ptep = pte_offset_map(pmdp, address);
+ if (!ptep)
+ goto out_irqs_on;
pte = *ptep;
if (!pte_present(pte))
goto out_unmap;
diff --git a/arch/sparc/mm/fault_64.c b/arch/sparc/mm/fault_64.c
index d91305de694c..d8a407fbe350 100644
--- a/arch/sparc/mm/fault_64.c
+++ b/arch/sparc/mm/fault_64.c
@@ -99,6 +99,7 @@ static unsigned int get_user_insn(unsigned long tpc)
local_irq_disable();
pmdp = pmd_offset(pudp, tpc);
+again:
if (pmd_none(*pmdp) || unlikely(pmd_bad(*pmdp)))
goto out_irq_enable;
@@ -115,6 +116,8 @@ static unsigned int get_user_insn(unsigned long tpc)
#endif
{
ptep = pte_offset_map(pmdp, tpc);
+ if (!ptep)
+ goto again;
pte = *ptep;
if (pte_present(pte)) {
pa = (pte_pfn(pte) << PAGE_SHIFT);
diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c
index 9a725547578e..7ecf8556947a 100644
--- a/arch/sparc/mm/tlb.c
+++ b/arch/sparc/mm/tlb.c
@@ -149,6 +149,8 @@ static void tlb_batch_pmd_scan(struct mm_struct *mm,
unsigned long vaddr,
pte_t *pte;
pte = pte_offset_map(, vaddr);
+ if (!pte)
+ return;
end = vaddr + HPAGE_SIZE;
while (vaddr < end) {
if (pte_val(*pte) & _PAGE_VALID) {
--
2.35.3
[PATCH 18/23] sparc/hugetlb: pte_alloc_huge() pte_offset_huge()
pte_alloc_map() expects to be followed by pte_unmap(), but hugetlb omits that: to keep balance in future, use the recently added pte_alloc_huge() instead; with pte_offset_huge() a better name for pte_offset_kernel(). Signed-off-by: Hugh Dickins --- arch/sparc/mm/hugetlbpage.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c index d8e0e3c7038d..d7018823206c 100644 --- a/arch/sparc/mm/hugetlbpage.c +++ b/arch/sparc/mm/hugetlbpage.c @@ -298,7 +298,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, return NULL; if (sz >= PMD_SIZE) return (pte_t *)pmd; - return pte_alloc_map(mm, pmd, addr); + return pte_alloc_huge(mm, pmd, addr); } pte_t *huge_pte_offset(struct mm_struct *mm, @@ -325,7 +325,7 @@ pte_t *huge_pte_offset(struct mm_struct *mm, return NULL; if (is_hugetlb_pmd(*pmd)) return (pte_t *)pmd; - return pte_offset_map(pmd, addr); + return pte_offset_huge(pmd, addr); } void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, -- 2.35.3
[PATCH 17/23] sh/hugetlb: pte_alloc_huge() pte_offset_huge()
pte_alloc_map() expects to be followed by pte_unmap(), but hugetlb omits
that: to keep balance in future, use the recently added pte_alloc_huge()
instead; with pte_offset_huge() a better name for pte_offset_kernel().
Signed-off-by: Hugh Dickins
---
arch/sh/mm/hugetlbpage.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/sh/mm/hugetlbpage.c b/arch/sh/mm/hugetlbpage.c
index 999ab5916e69..6cb0ad73dbb9 100644
--- a/arch/sh/mm/hugetlbpage.c
+++ b/arch/sh/mm/hugetlbpage.c
@@ -38,7 +38,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct
vm_area_struct *vma,
if (pud) {
pmd = pmd_alloc(mm, pud, addr);
if (pmd)
- pte = pte_alloc_map(mm, pmd, addr);
+ pte = pte_alloc_huge(mm, pmd, addr);
}
}
}
@@ -63,7 +63,7 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
if (pud) {
pmd = pmd_offset(pud, addr);
if (pmd)
- pte = pte_offset_map(pmd, addr);
+ pte = pte_offset_huge(pmd, addr);
}
}
}
--
2.35.3
[PATCH 16/23] s390: gmap use pte_unmap_unlock() not spin_unlock()
pte_alloc_map_lock() expects to be followed by pte_unmap_unlock(): to
keep balance in future, pass ptep as well as ptl to gmap_pte_op_end(),
and use pte_unmap_unlock() instead of direct spin_unlock() (even though
ptep ends up unused inside the macro).
Signed-off-by: Hugh Dickins
---
arch/s390/mm/gmap.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c
index d198fc9475a2..638dcd9bc820 100644
--- a/arch/s390/mm/gmap.c
+++ b/arch/s390/mm/gmap.c
@@ -895,12 +895,12 @@ static int gmap_pte_op_fixup(struct gmap *gmap, unsigned
long gaddr,
/**
* gmap_pte_op_end - release the page table lock
- * @ptl: pointer to the spinlock pointer
+ * @ptep: pointer to the locked pte
+ * @ptl: pointer to the page table spinlock
*/
-static void gmap_pte_op_end(spinlock_t *ptl)
+static void gmap_pte_op_end(pte_t *ptep, spinlock_t *ptl)
{
- if (ptl)
- spin_unlock(ptl);
+ pte_unmap_unlock(ptep, ptl);
}
/**
@@ -1011,7 +1011,7 @@ static int gmap_protect_pte(struct gmap *gmap, unsigned
long gaddr,
{
int rc;
pte_t *ptep;
- spinlock_t *ptl = NULL;
+ spinlock_t *ptl;
unsigned long pbits = 0;
if (pmd_val(*pmdp) & _SEGMENT_ENTRY_INVALID)
@@ -1025,7 +1025,7 @@ static int gmap_protect_pte(struct gmap *gmap, unsigned
long gaddr,
pbits |= (bits & GMAP_NOTIFY_SHADOW) ? PGSTE_VSIE_BIT : 0;
/* Protect and unlock. */
rc = ptep_force_prot(gmap->mm, gaddr, ptep, prot, pbits);
- gmap_pte_op_end(ptl);
+ gmap_pte_op_end(ptep, ptl);
return rc;
}
@@ -1154,7 +1154,7 @@ int gmap_read_table(struct gmap *gmap, unsigned long
gaddr, unsigned long *val)
/* Do *NOT* clear the _PAGE_INVALID bit! */
rc = 0;
}
- gmap_pte_op_end(ptl);
+ gmap_pte_op_end(ptep, ptl);
}
if (!rc)
break;
@@ -1248,7 +1248,7 @@ static int gmap_protect_rmap(struct gmap *sg, unsigned
long raddr,
if (!rc)
gmap_insert_rmap(sg, vmaddr, rmap);
spin_unlock(>guest_table_lock);
- gmap_pte_op_end(ptl);
+ gmap_pte_op_end(ptep, ptl);
}
radix_tree_preload_end();
if (rc) {
@@ -2156,7 +2156,7 @@ int gmap_shadow_page(struct gmap *sg, unsigned long
saddr, pte_t pte)
tptep = (pte_t *) gmap_table_walk(sg, saddr, 0);
if (!tptep) {
spin_unlock(>guest_table_lock);
- gmap_pte_op_end(ptl);
+ gmap_pte_op_end(sptep, ptl);
radix_tree_preload_end();
break;
}
@@ -2167,7 +2167,7 @@ int gmap_shadow_page(struct gmap *sg, unsigned long
saddr, pte_t pte)
rmap = NULL;
rc = 0;
}
- gmap_pte_op_end(ptl);
+ gmap_pte_op_end(sptep, ptl);
spin_unlock(>guest_table_lock);
}
radix_tree_preload_end();
@@ -2495,7 +2495,7 @@ void gmap_sync_dirty_log_pmd(struct gmap *gmap, unsigned
long bitmap[4],
continue;
if (ptep_test_and_clear_uc(gmap->mm, vmaddr, ptep))
set_bit(i, bitmap);
- spin_unlock(ptl);
+ pte_unmap_unlock(ptep, ptl);
}
}
gmap_pmd_op_end(gmap, pmdp);
--
2.35.3
[PATCH 15/23] s390: allow pte_offset_map_lock() to fail
In rare transient cases, not yet made possible, pte_offset_map() and
pte_offset_map_lock() may not find a page table: handle appropriately.
Signed-off-by: Hugh Dickins
---
arch/s390/kernel/uv.c | 2 ++
arch/s390/mm/gmap.c| 2 ++
arch/s390/mm/pgtable.c | 12 +---
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c
index cb2ee06df286..3c62d1b218b1 100644
--- a/arch/s390/kernel/uv.c
+++ b/arch/s390/kernel/uv.c
@@ -294,6 +294,8 @@ int gmap_make_secure(struct gmap *gmap, unsigned long
gaddr, void *uvcb)
rc = -ENXIO;
ptep = get_locked_pte(gmap->mm, uaddr, );
+ if (!ptep)
+ goto out;
if (pte_present(*ptep) && !(pte_val(*ptep) & _PAGE_INVALID) &&
pte_write(*ptep)) {
page = pte_page(*ptep);
rc = -EAGAIN;
diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c
index dc90d1eb0d55..d198fc9475a2 100644
--- a/arch/s390/mm/gmap.c
+++ b/arch/s390/mm/gmap.c
@@ -2549,6 +2549,8 @@ static int __zap_zero_pages(pmd_t *pmd, unsigned long
start,
spinlock_t *ptl;
ptep = pte_offset_map_lock(walk->mm, pmd, addr, );
+ if (!ptep)
+ break;
if (is_zero_pfn(pte_pfn(*ptep)))
ptep_xchg_direct(walk->mm, addr, ptep,
__pte(_PAGE_INVALID));
pte_unmap_unlock(ptep, ptl);
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 6effb24de6d9..3bd2ab2a9a34 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -829,7 +829,7 @@ int set_guest_storage_key(struct mm_struct *mm, unsigned
long addr,
default:
return -EFAULT;
}
-
+again:
ptl = pmd_lock(mm, pmdp);
if (!pmd_present(*pmdp)) {
spin_unlock(ptl);
@@ -850,6 +850,8 @@ int set_guest_storage_key(struct mm_struct *mm, unsigned
long addr,
spin_unlock(ptl);
ptep = pte_offset_map_lock(mm, pmdp, addr, );
+ if (!ptep)
+ goto again;
new = old = pgste_get_lock(ptep);
pgste_val(new) &= ~(PGSTE_GR_BIT | PGSTE_GC_BIT |
PGSTE_ACC_BITS | PGSTE_FP_BIT);
@@ -938,7 +940,7 @@ int reset_guest_reference_bit(struct mm_struct *mm,
unsigned long addr)
default:
return -EFAULT;
}
-
+again:
ptl = pmd_lock(mm, pmdp);
if (!pmd_present(*pmdp)) {
spin_unlock(ptl);
@@ -955,6 +957,8 @@ int reset_guest_reference_bit(struct mm_struct *mm,
unsigned long addr)
spin_unlock(ptl);
ptep = pte_offset_map_lock(mm, pmdp, addr, );
+ if (!ptep)
+ goto again;
new = old = pgste_get_lock(ptep);
/* Reset guest reference bit only */
pgste_val(new) &= ~PGSTE_GR_BIT;
@@ -1000,7 +1004,7 @@ int get_guest_storage_key(struct mm_struct *mm, unsigned
long addr,
default:
return -EFAULT;
}
-
+again:
ptl = pmd_lock(mm, pmdp);
if (!pmd_present(*pmdp)) {
spin_unlock(ptl);
@@ -1017,6 +1021,8 @@ int get_guest_storage_key(struct mm_struct *mm, unsigned
long addr,
spin_unlock(ptl);
ptep = pte_offset_map_lock(mm, pmdp, addr, );
+ if (!ptep)
+ goto again;
pgste = pgste_get_lock(ptep);
*key = (pgste_val(pgste) & (PGSTE_ACC_BITS | PGSTE_FP_BIT)) >> 56;
paddr = pte_val(*ptep) & PAGE_MASK;
--
2.35.3
[PATCH 14/23] riscv/hugetlb: pte_alloc_huge() pte_offset_huge()
pte_alloc_map() expects to be followed by pte_unmap(), but hugetlb omits
that: to keep balance in future, use the recently added pte_alloc_huge()
instead; with pte_offset_huge() a better name for pte_offset_kernel().
Signed-off-by: Hugh Dickins
---
arch/riscv/mm/hugetlbpage.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/mm/hugetlbpage.c b/arch/riscv/mm/hugetlbpage.c
index a163a3e0f0d4..80926946759f 100644
--- a/arch/riscv/mm/hugetlbpage.c
+++ b/arch/riscv/mm/hugetlbpage.c
@@ -43,7 +43,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
for_each_napot_order(order) {
if (napot_cont_size(order) == sz) {
- pte = pte_alloc_map(mm, pmd, addr &
napot_cont_mask(order));
+ pte = pte_alloc_huge(mm, pmd, addr &
napot_cont_mask(order));
break;
}
}
@@ -90,7 +90,7 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
for_each_napot_order(order) {
if (napot_cont_size(order) == sz) {
- pte = pte_offset_kernel(pmd, addr &
napot_cont_mask(order));
+ pte = pte_offset_huge(pmd, addr &
napot_cont_mask(order));
break;
}
}
--
2.35.3
[PATCH 13/23] powerpc/hugetlb: pte_alloc_huge()
pte_alloc_map() expects to be followed by pte_unmap(), but hugetlb omits that: to keep balance in future, use the recently added pte_alloc_huge() instead. huge_pte_offset() is using __find_linux_pte(), which is using pte_offset_kernel() - don't rename that to _huge, it's more complicated. Signed-off-by: Hugh Dickins --- arch/powerpc/mm/hugetlbpage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c index b900933507da..f7c683b672c1 100644 --- a/arch/powerpc/mm/hugetlbpage.c +++ b/arch/powerpc/mm/hugetlbpage.c @@ -183,7 +183,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, return NULL; if (IS_ENABLED(CONFIG_PPC_8xx) && pshift < PMD_SHIFT) - return pte_alloc_map(mm, (pmd_t *)hpdp, addr); + return pte_alloc_huge(mm, (pmd_t *)hpdp, addr); BUG_ON(!hugepd_none(*hpdp) && !hugepd_ok(*hpdp)); -- 2.35.3
[PATCH 12/23] powerpc: allow pte_offset_map[_lock]() to fail
In rare transient cases, not yet made possible, pte_offset_map() and
pte_offset_map_lock() may not find a page table: handle appropriately.
Balance successful pte_offset_map() with pte_unmap() where omitted.
Signed-off-by: Hugh Dickins
---
arch/powerpc/mm/book3s64/hash_tlb.c | 4
arch/powerpc/mm/book3s64/subpage_prot.c | 2 ++
arch/powerpc/xmon/xmon.c| 5 -
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/book3s64/hash_tlb.c
b/arch/powerpc/mm/book3s64/hash_tlb.c
index a64ea0a7ef96..21fcad97ae80 100644
--- a/arch/powerpc/mm/book3s64/hash_tlb.c
+++ b/arch/powerpc/mm/book3s64/hash_tlb.c
@@ -239,12 +239,16 @@ void flush_hash_table_pmd_range(struct mm_struct *mm,
pmd_t *pmd, unsigned long
local_irq_save(flags);
arch_enter_lazy_mmu_mode();
start_pte = pte_offset_map(pmd, addr);
+ if (!start_pte)
+ goto out;
for (pte = start_pte; pte < start_pte + PTRS_PER_PTE; pte++) {
unsigned long pteval = pte_val(*pte);
if (pteval & H_PAGE_HASHPTE)
hpte_need_flush(mm, addr, pte, pteval, 0);
addr += PAGE_SIZE;
}
+ pte_unmap(start_pte);
+out:
arch_leave_lazy_mmu_mode();
local_irq_restore(flags);
}
diff --git a/arch/powerpc/mm/book3s64/subpage_prot.c
b/arch/powerpc/mm/book3s64/subpage_prot.c
index b75a9fb99599..0dc85556dec5 100644
--- a/arch/powerpc/mm/book3s64/subpage_prot.c
+++ b/arch/powerpc/mm/book3s64/subpage_prot.c
@@ -71,6 +71,8 @@ static void hpte_flush_range(struct mm_struct *mm, unsigned
long addr,
if (pmd_none(*pmd))
return;
pte = pte_offset_map_lock(mm, pmd, addr, );
+ if (!pte)
+ return;
arch_enter_lazy_mmu_mode();
for (; npages > 0; --npages) {
pte_update(mm, addr, pte, 0, 0, 0);
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 728d3c257e4a..69447bdf0bcf 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -3376,12 +3376,15 @@ static void show_pte(unsigned long addr)
printf("pmdp @ 0x%px = 0x%016lx\n", pmdp, pmd_val(*pmdp));
ptep = pte_offset_map(pmdp, addr);
- if (pte_none(*ptep)) {
+ if (!ptep || pte_none(*ptep)) {
+ if (ptep)
+ pte_unmap(ptep);
printf("no valid PTE\n");
return;
}
format_pte(ptep, pte_val(*ptep));
+ pte_unmap(ptep);
sync();
__delay(200);
--
2.35.3
[PATCH 11/23] powerpc: kvmppc_unmap_free_pmd() pte_offset_kernel()
kvmppc_unmap_free_pmd() use pte_offset_kernel(), like everywhere else
in book3s_64_mmu_radix.c: instead of pte_offset_map(), which will come
to need a pte_unmap() to balance it.
But note that this is a more complex case than most: see those -EAGAINs
in kvmppc_create_pte(), which is coping with kvmppc races beween page
table and huge entry, of the kind which we are expecting to address
in pte_offset_map() - this might want to be revisited in future.
Signed-off-by: Hugh Dickins
---
arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c
b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index 461307b89c3a..572707858d65 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -509,7 +509,7 @@ static void kvmppc_unmap_free_pmd(struct kvm *kvm, pmd_t
*pmd, bool full,
} else {
pte_t *pte;
- pte = pte_offset_map(p, 0);
+ pte = pte_offset_kernel(p, 0);
kvmppc_unmap_free_pte(kvm, pte, full, lpid);
pmd_clear(p);
}
--
2.35.3
[PATCH 10/23] parisc/hugetlb: pte_alloc_huge() pte_offset_huge()
pte_alloc_map() expects to be followed by pte_unmap(), but hugetlb omits
that: to keep balance in future, use the recently added pte_alloc_huge()
instead; with pte_offset_huge() a better name for pte_offset_kernel().
Signed-off-by: Hugh Dickins
---
arch/parisc/mm/hugetlbpage.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/parisc/mm/hugetlbpage.c b/arch/parisc/mm/hugetlbpage.c
index d1d3990b83f6..a8a1a7c1e16e 100644
--- a/arch/parisc/mm/hugetlbpage.c
+++ b/arch/parisc/mm/hugetlbpage.c
@@ -66,7 +66,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct
vm_area_struct *vma,
if (pud) {
pmd = pmd_alloc(mm, pud, addr);
if (pmd)
- pte = pte_alloc_map(mm, pmd, addr);
+ pte = pte_alloc_huge(mm, pmd, addr);
}
return pte;
}
@@ -90,7 +90,7 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
if (!pud_none(*pud)) {
pmd = pmd_offset(pud, addr);
if (!pmd_none(*pmd))
- pte = pte_offset_map(pmd, addr);
+ pte = pte_offset_huge(pmd, addr);
}
}
}
--
2.35.3
[PATCH 09/23] parisc: unmap_uncached_pte() use pte_offset_kernel()
unmap_uncached_pte() is working from pgd_offset_k(vaddr), so it should use pte_offset_kernel() instead of pte_offset_map(), to avoid the question of whether a pte_unmap() will be needed to balance. Signed-off-by: Hugh Dickins --- arch/parisc/kernel/pci-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c index ba87f791323b..52d5f8a5cdd2 100644 --- a/arch/parisc/kernel/pci-dma.c +++ b/arch/parisc/kernel/pci-dma.c @@ -164,7 +164,7 @@ static inline void unmap_uncached_pte(pmd_t * pmd, unsigned long vaddr, pmd_clear(pmd); return; } - pte = pte_offset_map(pmd, vaddr); + pte = pte_offset_kernel(pmd, vaddr); vaddr &= ~PMD_MASK; end = vaddr + size; if (end > PMD_SIZE) -- 2.35.3
[PATCH 08/23] parisc: add pte_unmap() to balance get_ptep()
To keep balance in future, remember to pte_unmap() after a successful
get_ptep(). And (we might as well) pretend that flush_cache_pages()
really needed a map there, to read the pfn before "unmapping".
Signed-off-by: Hugh Dickins
---
arch/parisc/kernel/cache.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index 1d3b8bc8a623..b0c969b3a300 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -425,10 +425,15 @@ void flush_dcache_page(struct page *page)
offset = (pgoff - mpnt->vm_pgoff) << PAGE_SHIFT;
addr = mpnt->vm_start + offset;
if (parisc_requires_coherency()) {
+ bool needs_flush = false;
pte_t *ptep;
ptep = get_ptep(mpnt->vm_mm, addr);
- if (ptep && pte_needs_flush(*ptep))
+ if (ptep) {
+ needs_flush = pte_needs_flush(*ptep);
+ pte_unmap(ptep);
+ }
+ if (needs_flush)
flush_user_cache_page(mpnt, addr);
} else {
/*
@@ -560,14 +565,20 @@ EXPORT_SYMBOL(flush_kernel_dcache_page_addr);
static void flush_cache_page_if_present(struct vm_area_struct *vma,
unsigned long vmaddr, unsigned long pfn)
{
- pte_t *ptep = get_ptep(vma->vm_mm, vmaddr);
+ bool needs_flush = false;
+ pte_t *ptep;
/*
* The pte check is racy and sometimes the flush will trigger
* a non-access TLB miss. Hopefully, the page has already been
* flushed.
*/
- if (ptep && pte_needs_flush(*ptep))
+ ptep = get_ptep(vma->vm_mm, vmaddr);
+ if (ptep) {
+ needs_flush = pte_needs_flush(*ptep))
+ pte_unmap(ptep);
+ }
+ if (needs_flush)
flush_cache_page(vma, vmaddr, pfn);
}
@@ -634,17 +645,22 @@ static void flush_cache_pages(struct vm_area_struct *vma,
unsigned long start, u
pte_t *ptep;
for (addr = start; addr < end; addr += PAGE_SIZE) {
+ bool needs_flush = false;
/*
* The vma can contain pages that aren't present. Although
* the pte search is expensive, we need the pte to find the
* page pfn and to check whether the page should be flushed.
*/
ptep = get_ptep(vma->vm_mm, addr);
- if (ptep && pte_needs_flush(*ptep)) {
+ if (ptep) {
+ needs_flush = pte_needs_flush(*ptep);
+ pfn = pte_pfn(*ptep);
+ pte_unmap(ptep);
+ }
+ if (needs_flush) {
if (parisc_requires_coherency()) {
flush_user_cache_page(vma, addr);
} else {
- pfn = pte_pfn(*ptep);
if (WARN_ON(!pfn_valid(pfn)))
return;
__flush_cache_page(vma, addr, PFN_PHYS(pfn));
--
2.35.3
[PATCH 07/23] mips: update_mmu_cache() can replace __update_tlb()
Don't make update_mmu_cache() a wrapper around __update_tlb(): call it
directly, and use the ptep (or pmdp) provided by the caller, instead of
re-calling pte_offset_map() - which would raise a question of whether a
pte_unmap() is needed to balance it.
Check whether the "ptep" provided by the caller is actually the pmdp,
instead of testing pmd_huge(): or test pmd_huge() too and warn if it
disagrees? This is "hazardous" territory: needs review and testing.
Signed-off-by: Hugh Dickins
---
arch/mips/include/asm/pgtable.h | 15 +++
arch/mips/mm/tlb-r3k.c | 5 +++--
arch/mips/mm/tlb-r4k.c | 9 +++--
3 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
index 574fa14ac8b2..9175dfab08d5 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -565,15 +565,8 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
}
#endif
-extern void __update_tlb(struct vm_area_struct *vma, unsigned long address,
- pte_t pte);
-
-static inline void update_mmu_cache(struct vm_area_struct *vma,
- unsigned long address, pte_t *ptep)
-{
- pte_t pte = *ptep;
- __update_tlb(vma, address, pte);
-}
+extern void update_mmu_cache(struct vm_area_struct *vma,
+ unsigned long address, pte_t *ptep);
#define__HAVE_ARCH_UPDATE_MMU_TLB
#define update_mmu_tlb update_mmu_cache
@@ -581,9 +574,7 @@ static inline void update_mmu_cache(struct vm_area_struct
*vma,
static inline void update_mmu_cache_pmd(struct vm_area_struct *vma,
unsigned long address, pmd_t *pmdp)
{
- pte_t pte = *(pte_t *)pmdp;
-
- __update_tlb(vma, address, pte);
+ update_mmu_cache(vma, address, (pte_t *)pmdp);
}
/*
diff --git a/arch/mips/mm/tlb-r3k.c b/arch/mips/mm/tlb-r3k.c
index 53dfa2b9316b..e5722cd8dd6d 100644
--- a/arch/mips/mm/tlb-r3k.c
+++ b/arch/mips/mm/tlb-r3k.c
@@ -176,7 +176,8 @@ void local_flush_tlb_page(struct vm_area_struct *vma,
unsigned long page)
}
}
-void __update_tlb(struct vm_area_struct *vma, unsigned long address, pte_t pte)
+void update_mmu_cache(struct vm_area_struct *vma,
+ unsigned long address, pte_t *ptep)
{
unsigned long asid_mask = cpu_asid_mask(_cpu_data);
unsigned long flags;
@@ -203,7 +204,7 @@ void __update_tlb(struct vm_area_struct *vma, unsigned long
address, pte_t pte)
BARRIER;
tlb_probe();
idx = read_c0_index();
- write_c0_entrylo0(pte_val(pte));
+ write_c0_entrylo0(pte_val(*ptep));
write_c0_entryhi(address | pid);
if (idx < 0) { /* BARRIER */
tlb_write_random();
diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c
index 1b939abbe4ca..c96725d17cab 100644
--- a/arch/mips/mm/tlb-r4k.c
+++ b/arch/mips/mm/tlb-r4k.c
@@ -290,14 +290,14 @@ void local_flush_tlb_one(unsigned long page)
* updates the TLB with the new pte(s), and another which also checks
* for the R4k "end of page" hardware bug and does the needy.
*/
-void __update_tlb(struct vm_area_struct * vma, unsigned long address, pte_t
pte)
+void update_mmu_cache(struct vm_area_struct *vma,
+ unsigned long address, pte_t *ptep)
{
unsigned long flags;
pgd_t *pgdp;
p4d_t *p4dp;
pud_t *pudp;
pmd_t *pmdp;
- pte_t *ptep;
int idx, pid;
/*
@@ -326,10 +326,9 @@ void __update_tlb(struct vm_area_struct * vma, unsigned
long address, pte_t pte)
idx = read_c0_index();
#ifdef CONFIG_MIPS_HUGE_TLB_SUPPORT
/* this could be a huge page */
- if (pmd_huge(*pmdp)) {
+ if (ptep == (pte_t *)pmdp) {
unsigned long lo;
write_c0_pagemask(PM_HUGE_MASK);
- ptep = (pte_t *)pmdp;
lo = pte_to_entrylo(pte_val(*ptep));
write_c0_entrylo0(lo);
write_c0_entrylo1(lo + (HPAGE_SIZE >> 7));
@@ -344,8 +343,6 @@ void __update_tlb(struct vm_area_struct * vma, unsigned
long address, pte_t pte)
} else
#endif
{
- ptep = pte_offset_map(pmdp, address);
-
#if defined(CONFIG_PHYS_ADDR_T_64BIT) && defined(CONFIG_CPU_MIPS32)
#ifdef CONFIG_XPA
write_c0_entrylo0(pte_to_entrylo(ptep->pte_high));
--
2.35.3
[PATCH 06/23] microblaze: allow pte_offset_map() to fail
In rare transient cases, not yet made possible, pte_offset_map() and
pte_offset_map_lock() may not find a page table: handle appropriately.
Signed-off-by: Hugh Dickins
---
arch/microblaze/kernel/signal.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/microblaze/kernel/signal.c b/arch/microblaze/kernel/signal.c
index c3aebec71c0c..c78a0ff48066 100644
--- a/arch/microblaze/kernel/signal.c
+++ b/arch/microblaze/kernel/signal.c
@@ -194,7 +194,7 @@ static int setup_rt_frame(struct ksignal *ksig, sigset_t
*set,
preempt_disable();
ptep = pte_offset_map(pmdp, address);
- if (pte_present(*ptep)) {
+ if (ptep && pte_present(*ptep)) {
address = (unsigned long) page_address(pte_page(*ptep));
/* MS: I need add offset in page */
address += ((unsigned long)frame->tramp) & ~PAGE_MASK;
@@ -203,7 +203,8 @@ static int setup_rt_frame(struct ksignal *ksig, sigset_t
*set,
invalidate_icache_range(address, address + 8);
flush_dcache_range(address, address + 8);
}
- pte_unmap(ptep);
+ if (ptep)
+ pte_unmap(ptep);
preempt_enable();
if (err)
return -EFAULT;
--
2.35.3
[PATCH 05/23] m68k: allow pte_offset_map[_lock]() to fail
In rare transient cases, not yet made possible, pte_offset_map() and
pte_offset_map_lock() may not find a page table: handle appropriately.
Restructure cf_tlb_miss() with a pte_unmap() (previously omitted)
at label out, followed by one local_irq_restore() for all.
Signed-off-by: Hugh Dickins
---
arch/m68k/include/asm/mmu_context.h | 6 ++--
arch/m68k/kernel/sys_m68k.c | 2 ++
arch/m68k/mm/mcfmmu.c | 52 -
3 files changed, 27 insertions(+), 33 deletions(-)
diff --git a/arch/m68k/include/asm/mmu_context.h
b/arch/m68k/include/asm/mmu_context.h
index 8ed6ac14d99f..141bbdfad960 100644
--- a/arch/m68k/include/asm/mmu_context.h
+++ b/arch/m68k/include/asm/mmu_context.h
@@ -99,7 +99,7 @@ static inline void load_ksp_mmu(struct task_struct *task)
p4d_t *p4d;
pud_t *pud;
pmd_t *pmd;
- pte_t *pte;
+ pte_t *pte = NULL;
unsigned long mmuar;
local_irq_save(flags);
@@ -139,7 +139,7 @@ static inline void load_ksp_mmu(struct task_struct *task)
pte = (mmuar >= PAGE_OFFSET) ? pte_offset_kernel(pmd, mmuar)
: pte_offset_map(pmd, mmuar);
- if (pte_none(*pte) || !pte_present(*pte))
+ if (!pte || pte_none(*pte) || !pte_present(*pte))
goto bug;
set_pte(pte, pte_mkyoung(*pte));
@@ -161,6 +161,8 @@ static inline void load_ksp_mmu(struct task_struct *task)
bug:
pr_info("ksp load failed: mm=0x%p ksp=0x08%lx\n", mm, mmuar);
end:
+ if (pte && mmuar < PAGE_OFFSET)
+ pte_unmap(pte);
local_irq_restore(flags);
}
diff --git a/arch/m68k/kernel/sys_m68k.c b/arch/m68k/kernel/sys_m68k.c
index bd0274c7592e..c586034d2a7a 100644
--- a/arch/m68k/kernel/sys_m68k.c
+++ b/arch/m68k/kernel/sys_m68k.c
@@ -488,6 +488,8 @@ sys_atomic_cmpxchg_32(unsigned long newval, int oldval, int
d3, int d4, int d5,
if (!pmd_present(*pmd))
goto bad_access;
pte = pte_offset_map_lock(mm, pmd, (unsigned long)mem, );
+ if (!pte)
+ goto bad_access;
if (!pte_present(*pte) || !pte_dirty(*pte)
|| !pte_write(*pte)) {
pte_unmap_unlock(pte, ptl);
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 70aa0979e027..42f45abea37a 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -91,7 +91,8 @@ int cf_tlb_miss(struct pt_regs *regs, int write, int dtlb,
int extension_word)
p4d_t *p4d;
pud_t *pud;
pmd_t *pmd;
- pte_t *pte;
+ pte_t *pte = NULL;
+ int ret = -1;
int asid;
local_irq_save(flags);
@@ -100,47 +101,33 @@ int cf_tlb_miss(struct pt_regs *regs, int write, int
dtlb, int extension_word)
regs->pc + (extension_word * sizeof(long));
mm = (!user_mode(regs) && KMAPAREA(mmuar)) ? _mm : current->mm;
- if (!mm) {
- local_irq_restore(flags);
- return -1;
- }
+ if (!mm)
+ goto out;
pgd = pgd_offset(mm, mmuar);
- if (pgd_none(*pgd)) {
- local_irq_restore(flags);
- return -1;
- }
+ if (pgd_none(*pgd))
+ goto out;
p4d = p4d_offset(pgd, mmuar);
- if (p4d_none(*p4d)) {
- local_irq_restore(flags);
- return -1;
- }
+ if (p4d_none(*p4d))
+ goto out;
pud = pud_offset(p4d, mmuar);
- if (pud_none(*pud)) {
- local_irq_restore(flags);
- return -1;
- }
+ if (pud_none(*pud))
+ goto out;
pmd = pmd_offset(pud, mmuar);
- if (pmd_none(*pmd)) {
- local_irq_restore(flags);
- return -1;
- }
+ if (pmd_none(*pmd))
+ goto out;
pte = (KMAPAREA(mmuar)) ? pte_offset_kernel(pmd, mmuar)
: pte_offset_map(pmd, mmuar);
- if (pte_none(*pte) || !pte_present(*pte)) {
- local_irq_restore(flags);
- return -1;
- }
+ if (!pte || pte_none(*pte) || !pte_present(*pte))
+ goto out;
if (write) {
- if (!pte_write(*pte)) {
- local_irq_restore(flags);
- return -1;
- }
+ if (!pte_write(*pte))
+ goto out;
set_pte(pte, pte_mkdirty(*pte));
}
@@ -161,9 +148,12 @@ int cf_tlb_miss(struct pt_regs *regs, int write, int dtlb,
int extension_word)
mmu_write(MMUOR, MMUOR_ACC | MMUOR_UAA);
else
mmu_write(MMUOR, MMUOR_ITLB | MMUOR_ACC | MMUOR_UAA);
-
+ ret = 0;
+out:
+ if (pte && !KMAPAREA(mmuar))
+ pte_unmap(pte);
local_irq_restore(flags);
- return 0;
+ return ret;
}
void __init
[PATCH 04/23] ia64/hugetlb: pte_alloc_huge() pte_offset_huge()
pte_alloc_map() expects to be followed by pte_unmap(), but hugetlb omits
that: to keep balance in future, use the recently added pte_alloc_huge()
instead; with pte_offset_huge() a better name for pte_offset_kernel().
Signed-off-by: Hugh Dickins
---
arch/ia64/mm/hugetlbpage.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/mm/hugetlbpage.c b/arch/ia64/mm/hugetlbpage.c
index 78a02e026164..adc49f2d22e8 100644
--- a/arch/ia64/mm/hugetlbpage.c
+++ b/arch/ia64/mm/hugetlbpage.c
@@ -41,7 +41,7 @@ huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct
*vma,
if (pud) {
pmd = pmd_alloc(mm, pud, taddr);
if (pmd)
- pte = pte_alloc_map(mm, pmd, taddr);
+ pte = pte_alloc_huge(mm, pmd, taddr);
}
return pte;
}
@@ -64,7 +64,7 @@ huge_pte_offset (struct mm_struct *mm, unsigned long addr,
unsigned long sz)
if (pud_present(*pud)) {
pmd = pmd_offset(pud, taddr);
if (pmd_present(*pmd))
- pte = pte_offset_map(pmd, taddr);
+ pte = pte_offset_huge(pmd, taddr);
}
}
}
--
2.35.3
[PATCH 03/23] arm64/hugetlb: pte_alloc_huge() pte_offset_huge()
pte_alloc_map() expects to be followed by pte_unmap(), but hugetlb omits
that: to keep balance in future, use the recently added pte_alloc_huge()
instead; with pte_offset_huge() a better name for pte_offset_kernel().
Signed-off-by: Hugh Dickins
---
arch/arm64/mm/hugetlbpage.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 95364e8bdc19..21716c940682 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -307,14 +307,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct
vm_area_struct *vma,
return NULL;
WARN_ON(addr & (sz - 1));
- /*
-* Note that if this code were ever ported to the
-* 32-bit arm platform then it will cause trouble in
-* the case where CONFIG_HIGHPTE is set, since there
-* will be no pte_unmap() to correspond with this
-* pte_alloc_map().
-*/
- ptep = pte_alloc_map(mm, pmdp, addr);
+ ptep = pte_alloc_huge(mm, pmdp, addr);
} else if (sz == PMD_SIZE) {
if (want_pmd_share(vma, addr) && pud_none(READ_ONCE(*pudp)))
ptep = huge_pmd_share(mm, vma, addr, pudp);
@@ -366,7 +359,7 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
return (pte_t *)pmdp;
if (sz == CONT_PTE_SIZE)
- return pte_offset_kernel(pmdp, (addr & CONT_PTE_MASK));
+ return pte_offset_huge(pmdp, (addr & CONT_PTE_MASK));
return NULL;
}
--
2.35.3
[PATCH 02/23] arm64: allow pte_offset_map() to fail
In rare transient cases, not yet made possible, pte_offset_map() and
pte_offset_map_lock() may not find a page table: handle appropriately.
Signed-off-by: Hugh Dickins
---
arch/arm64/mm/fault.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 9e0db5c387e3..a58780d5fac4 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -177,6 +177,9 @@ static void show_pte(unsigned long addr)
break;
ptep = pte_offset_map(pmdp, addr);
+ if (!ptep)
+ break;
+
pte = READ_ONCE(*ptep);
pr_cont(", pte=%016llx", pte_val(pte));
pte_unmap(ptep);
--
2.35.3
[PATCH 01/23] arm: allow pte_offset_map[_lock]() to fail
In rare transient cases, not yet made possible, pte_offset_map() and
pte_offset_map_lock() may not find a page table: handle appropriately.
Signed-off-by: Hugh Dickins
---
arch/arm/lib/uaccess_with_memcpy.c | 3 +++
arch/arm/mm/fault-armv.c | 5 -
arch/arm/mm/fault.c| 3 +++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/lib/uaccess_with_memcpy.c
b/arch/arm/lib/uaccess_with_memcpy.c
index e4c2677cc1e9..2f6163f05e93 100644
--- a/arch/arm/lib/uaccess_with_memcpy.c
+++ b/arch/arm/lib/uaccess_with_memcpy.c
@@ -74,6 +74,9 @@ pin_page_for_write(const void __user *_addr, pte_t **ptep,
spinlock_t **ptlp)
return 0;
pte = pte_offset_map_lock(current->mm, pmd, addr, );
+ if (unlikely(!pte))
+ return 0;
+
if (unlikely(!pte_present(*pte) || !pte_young(*pte) ||
!pte_write(*pte) || !pte_dirty(*pte))) {
pte_unmap_unlock(pte, ptl);
diff --git a/arch/arm/mm/fault-armv.c b/arch/arm/mm/fault-armv.c
index 0e49154454a6..ca5302b0b7ee 100644
--- a/arch/arm/mm/fault-armv.c
+++ b/arch/arm/mm/fault-armv.c
@@ -117,8 +117,11 @@ static int adjust_pte(struct vm_area_struct *vma, unsigned
long address,
* must use the nested version. This also means we need to
* open-code the spin-locking.
*/
- ptl = pte_lockptr(vma->vm_mm, pmd);
pte = pte_offset_map(pmd, address);
+ if (!pte)
+ return 0;
+
+ ptl = pte_lockptr(vma->vm_mm, pmd);
do_pte_lock(ptl);
ret = do_adjust_pte(vma, address, pfn, pte);
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 2418f1efabd8..83598649a094 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -85,6 +85,9 @@ void show_pte(const char *lvl, struct mm_struct *mm, unsigned
long addr)
break;
pte = pte_offset_map(pmd, addr);
+ if (!pte)
+ break;
+
pr_cont(", *pte=%08llx", (long long)pte_val(*pte));
#ifndef CONFIG_ARM_LPAE
pr_cont(", *ppte=%08llx",
--
2.35.3
[PATCH 00/23] arch: allow pte_offset_map[_lock]() to fail
Here is a series of patches to various architectures, based on v6.4-rc1: preparing for changes expected to follow in mm, affecting pte_offset_map() and pte_offset_map_lock(). In a week or two, I intend to post a separate series, of equivalent preparations in mm. These two series are "independent": neither depends for build or correctness on the other, and the arch patches can be merged separately via arch trees (stragglers picked up by akpm?); but both series have to be in before a third series is added to make the effective changes (and that will add a just a little more in powerpc, s390 and sparc). What is it all about? Some mmap_lock avoidance i.e. latency reduction. Initially just for the case of collapsing shmem or file pages to THPs; but likely to be relied upon later in other contexts e.g. freeing of empty page tables (but that's not work I'm doing). mmap_write_lock avoidance when collapsing to anon THPs? Perhaps, but again that's not work I've done: a quick and easy attempt looked like it was going to shift the load from mmap rwsem to pmd spinlock - not an improvement. I would much prefer not to have to make these small but wide-ranging changes for such a niche case; but failed to find another way, and have heard that shmem MADV_COLLAPSE's usefulness is being limited by that mmap_write_lock it currently requires. These changes (though of course not these exact patches, and not all of these architectures!) have been in Google's data centre kernel for three years now: we do rely upon them. What are the per-arch changes about? Generally, two things. One: the current mmap locking may not be enough to guard against that tricky transition between pmd entry pointing to page table, and empty pmd entry, and pmd entry pointing to huge page: pte_offset_map() will have to validate the pmd entry for itself, returning NULL if no page table is there. What to do about that varies: often the nearby error handling indicates just to skip it; but in some cases a "goto again" looks appropriate (and if that risks an infinite loop, then there must have been an oops, or pfn 0 mistaken for page table, before). Deeper study of each site might show that 90% of them here in arch code could only fail if there's corruption e.g. a transition to THP would be surprising on an arch without HAVE_ARCH_TRANSPARENT_HUGEPAGE. But given the likely extension to freeing empty page tables, I have not limited this set of changes to THP; and it has been easier, and sets a better example, if each site is given appropriate handling. Two: pte_offset_map() will need to do an rcu_read_lock(), with the corresponding rcu_read_unlock() in pte_unmap(). But most architectures never supported CONFIG_HIGHPTE, so some don't always call pte_unmap() after pte_offset_map(), or have used userspace pte_offset_map() where pte_offset_kernel() is more correct. No problem in the current tree, but a problem once an rcu_read_unlock() will be needed to keep balance. A common special case of that comes in arch/*/mm/hugetlbpage.c, if the architecture supports hugetlb pages down at the lowest PTE level. huge_pte_alloc() uses pte_alloc_map(), but generic hugetlb code does no corresponding pte_unmap(); similarly for huge_pte_offset(). Thanks to Mike Kravetz and Andrew Morton, v6.4-rc1 already provides pte_alloc_huge() and pte_offset_huge() to help fix up those cases. 01/23 arm: allow pte_offset_map[_lock]() to fail 02/23 arm64: allow pte_offset_map() to fail 03/23 arm64/hugetlb: pte_alloc_huge() pte_offset_huge() 04/23 ia64/hugetlb: pte_alloc_huge() pte_offset_huge() 05/23 m68k: allow pte_offset_map[_lock]() to fail 06/23 microblaze: allow pte_offset_map() to fail 07/23 mips: update_mmu_cache() can replace __update_tlb() 08/23 parisc: add pte_unmap() to balance get_ptep() 09/23 parisc: unmap_uncached_pte() use pte_offset_kernel() 10/23 parisc/hugetlb: pte_alloc_huge() pte_offset_huge() 11/23 powerpc: kvmppc_unmap_free_pmd() pte_offset_kernel() 12/23 powerpc: allow pte_offset_map[_lock]() to fail 13/23 powerpc/hugetlb: pte_alloc_huge() 14/23 riscv/hugetlb: pte_alloc_huge() pte_offset_huge() 15/23 s390: allow pte_offset_map_lock() to fail 16/23 s390: gmap use pte_unmap_unlock() not spin_unlock() 17/23 sh/hugetlb: pte_alloc_huge() pte_offset_huge() 18/23 sparc/hugetlb: pte_alloc_huge() pte_offset_huge() 19/23 sparc: allow pte_offset_map() to fail 20/23 sparc: iounit and iommu use pte_offset_kernel() 21/23 x86: Allow get_locked_pte() to fail 22/23 x86: sme_populate_pgd() use pte_offset_kernel() 23/23 xtensa: add pte_unmap() to balance pte_offset_map() arch/arm/lib/uaccess_with_memcpy.c | 3 ++ arch/arm/mm/fault-armv.c| 5 ++- arch/arm/mm/fault.c | 3 ++ arch/arm64/mm/fault.c | 3 ++ arch/arm64/mm/hugetlbpage.c | 11 ++ arch/ia64/mm/hugetlbpage.c | 4 +-- arch/m68k/include/asm/mmu_context.h | 6 ++-- arch/m68k/kernel/sys_m68k.c | 2 ++
[PATCH v2 09/11] powerpc: powernv: Annotate data races in opal events
The kopald thread handles opal events as they appear, but by polling a
static bit-vector in last_outstanding_events. Annotate these data races
accordingly. We are not at risk of missing events, but use of READ_ONCE,
WRITE_ONCE will assist readers in seeing that kopald only consumes the
events it is aware of when it is scheduled. Also removes extraneous
KCSAN warnings.
Signed-off-by: Rohan McLure
Reviewed-by: Nicholas Piggin
---
arch/powerpc/platforms/powernv/opal-irqchip.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-irqchip.c
b/arch/powerpc/platforms/powernv/opal-irqchip.c
index d55652b5f6fa..f9a7001dacb7 100644
--- a/arch/powerpc/platforms/powernv/opal-irqchip.c
+++ b/arch/powerpc/platforms/powernv/opal-irqchip.c
@@ -59,7 +59,7 @@ void opal_handle_events(void)
cond_resched();
}
- last_outstanding_events = 0;
+ WRITE_ONCE(last_outstanding_events, 0);
if (opal_poll_events() != OPAL_SUCCESS)
return;
e = be64_to_cpu(events) & opal_event_irqchip.mask;
@@ -69,7 +69,7 @@ void opal_handle_events(void)
bool opal_have_pending_events(void)
{
- if (last_outstanding_events & opal_event_irqchip.mask)
+ if (READ_ONCE(last_outstanding_events) & opal_event_irqchip.mask)
return true;
return false;
}
@@ -124,7 +124,7 @@ static irqreturn_t opal_interrupt(int irq, void *data)
__be64 events;
opal_handle_interrupt(virq_to_hw(irq), );
- last_outstanding_events = be64_to_cpu(events);
+ WRITE_ONCE(last_outstanding_events, be64_to_cpu(events));
if (opal_have_pending_events())
opal_wake_poller();
--
2.37.2
[PATCH v2 11/11] powerpc: Mark asynchronous accesses to irq_data
KCSAN revealed that while irq_data entries are written to either from
behind a mutex, or otherwise atomically, accesses to irq_data->hwirq can
occur asynchronously, without volatile annotation. Mark these accesses
with READ_ONCE to avoid unfortunate compiler reorderings and remove
KCSAN warnings.
Signed-off-by: Rohan McLure
---
arch/powerpc/kernel/irq.c | 2 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 12 ++--
include/linux/irq.h | 2 +-
kernel/irq/irqdomain.c| 4 ++--
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 6f7d4edaa0bc..4ac192755510 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -353,7 +353,7 @@ void do_softirq_own_stack(void)
irq_hw_number_t virq_to_hw(unsigned int virq)
{
struct irq_data *irq_data = irq_get_irq_data(virq);
- return WARN_ON(!irq_data) ? 0 : irq_data->hwirq;
+ return WARN_ON(!irq_data) ? 0 : READ_ONCE(irq_data->hwirq);
}
EXPORT_SYMBOL_GPL(virq_to_hw);
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index f851f4983423..141491e86bba 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1986,7 +1986,7 @@ int64_t pnv_opal_pci_msi_eoi(struct irq_data *d)
struct pci_controller *hose =
irq_data_get_irq_chip_data(d->parent_data);
struct pnv_phb *phb = hose->private_data;
- return opal_pci_msi_eoi(phb->opal_id, d->parent_data->hwirq);
+ return opal_pci_msi_eoi(phb->opal_id, READ_ONCE(d->parent_data->hwirq));
}
/*
@@ -2162,11 +2162,11 @@ static void pnv_msi_compose_msg(struct irq_data *d,
struct msi_msg *msg)
struct pnv_phb *phb = hose->private_data;
int rc;
- rc = __pnv_pci_ioda_msi_setup(phb, pdev, d->hwirq,
+ rc = __pnv_pci_ioda_msi_setup(phb, pdev, READ_ONCE(d->hwirq),
entry->pci.msi_attrib.is_64, msg);
if (rc)
dev_err(>dev, "Failed to setup %s-bit MSI #%ld : %d\n",
- entry->pci.msi_attrib.is_64 ? "64" : "32", d->hwirq,
rc);
+ entry->pci.msi_attrib.is_64 ? "64" : "32",
data_race(d->hwirq), rc);
}
/*
@@ -2184,7 +2184,7 @@ static void pnv_msi_eoi(struct irq_data *d)
* since it is translated into a vector number in
* OPAL, use that directly.
*/
- WARN_ON_ONCE(opal_pci_msi_eoi(phb->opal_id, d->hwirq));
+ WARN_ON_ONCE(opal_pci_msi_eoi(phb->opal_id,
READ_ONCE(d->hwirq)));
}
irq_chip_eoi_parent(d);
@@ -2263,9 +2263,9 @@ static void pnv_irq_domain_free(struct irq_domain
*domain, unsigned int virq,
struct pnv_phb *phb = hose->private_data;
pr_debug("%s bridge %pOF %d/%lx #%d\n", __func__, hose->dn,
-virq, d->hwirq, nr_irqs);
+virq, data_race(d->hwirq), nr_irqs);
- msi_bitmap_free_hwirqs(>msi_bmp, d->hwirq, nr_irqs);
+ msi_bitmap_free_hwirqs(>msi_bmp, READ_ONCE(d->hwirq), nr_irqs);
/* XIVE domain is cleared through ->msi_free() */
}
diff --git a/include/linux/irq.h b/include/linux/irq.h
index b1b28affb32a..a6888bcb3c5b 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -452,7 +452,7 @@ static inline bool irqd_affinity_on_activate(struct
irq_data *d)
static inline irq_hw_number_t irqd_to_hwirq(struct irq_data *d)
{
- return d->hwirq;
+ return READ_ONCE(d->hwirq);
}
/**
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index f34760a1e222..dd9054494f84 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -549,7 +549,7 @@ static void irq_domain_disassociate(struct irq_domain
*domain, unsigned int irq)
"virq%i doesn't exist; cannot disassociate\n", irq))
return;
- hwirq = irq_data->hwirq;
+ hwirq = READ_ONCE(irq_data->hwirq);
mutex_lock(>root->mutex);
@@ -948,7 +948,7 @@ struct irq_desc *__irq_resolve_mapping(struct irq_domain
*domain,
if (irq_domain_is_nomap(domain)) {
if (hwirq < domain->hwirq_max) {
data = irq_domain_get_irq_data(domain, hwirq);
- if (data && data->hwirq == hwirq)
+ if (data && READ_ONCE(data->hwirq) == hwirq)
desc = irq_data_to_desc(data);
if (irq && desc)
*irq = hwirq;
--
2.37.2
[PATCH v2 04/11] powerpc: Mark [h]ssr_valid accesses in check_return_regs_valid
Checks to see if the [H]SRR registers have been clobbered by (soft)
NMI interrupts imply the possibility for a data race on the
[h]srr_valid entries in the PACA. Annotate accesses to these fields with
READ_ONCE, removing the need for the barrier.
The diagnostic can use plain-access reads and writes, but annotate with
data_race.
Signed-off-by: Rohan McLure
Reported-by: Michael Ellerman
Reviewed-by: Nicholas Piggin
---
arch/powerpc/include/asm/ptrace.h | 4 ++--
arch/powerpc/kernel/interrupt.c | 14 ++
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h
b/arch/powerpc/include/asm/ptrace.h
index 0eb90a013346..9db8b16567e2 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -180,8 +180,8 @@ void do_syscall_trace_leave(struct pt_regs *regs);
static inline void set_return_regs_changed(void)
{
#ifdef CONFIG_PPC_BOOK3S_64
- local_paca->hsrr_valid = 0;
- local_paca->srr_valid = 0;
+ WRITE_ONCE(local_paca->hsrr_valid, 0);
+ WRITE_ONCE(local_paca->srr_valid, 0);
#endif
}
diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c
index e34c72285b4e..1f033f11b871 100644
--- a/arch/powerpc/kernel/interrupt.c
+++ b/arch/powerpc/kernel/interrupt.c
@@ -125,7 +125,7 @@ static notrace void check_return_regs_valid(struct pt_regs
*regs)
case 0x1600:
case 0x1800:
validp = _paca->hsrr_valid;
- if (!*validp)
+ if (!READ_ONCE(*validp))
return;
srr0 = mfspr(SPRN_HSRR0);
@@ -135,7 +135,7 @@ static notrace void check_return_regs_valid(struct pt_regs
*regs)
break;
default:
validp = _paca->srr_valid;
- if (!*validp)
+ if (!READ_ONCE(*validp))
return;
srr0 = mfspr(SPRN_SRR0);
@@ -161,19 +161,17 @@ static notrace void check_return_regs_valid(struct
pt_regs *regs)
* such things will get caught most of the time, statistically
* enough to be able to get a warning out.
*/
- barrier();
-
- if (!*validp)
+ if (!READ_ONCE(*validp))
return;
- if (!warned) {
- warned = true;
+ if (!data_race(warned)) {
+ data_race(warned = true);
printk("%sSRR0 was: %lx should be: %lx\n", h, srr0, regs->nip);
printk("%sSRR1 was: %lx should be: %lx\n", h, srr1, regs->msr);
show_regs(regs);
}
- *validp = 0; /* fixup */
+ WRITE_ONCE(*validp, 0); /* fixup */
#endif
}
--
2.37.2
[PATCH v2 08/11] powerpc: Mark writes registering ipi to host cpu through kvm and polling
Mark writes to hypervisor ipi state so that KCSAN recognises these
asynchronous issue of kvmppc_{set,clear}_host_ipi to be intended, with
atomic writes. Mark asynchronous polls to this variable in
kvm_ppc_read_one_intr().
Signed-off-by: Rohan McLure
---
v2: Add read-side annotations to both polling locations in
kvm_ppc_read_one_intr().
---
arch/powerpc/include/asm/kvm_ppc.h | 4 ++--
arch/powerpc/kvm/book3s_hv_builtin.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index bc57d058ad5b..d701df006c08 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -548,12 +548,12 @@ static inline void kvmppc_set_host_ipi(int cpu)
* pairs with the barrier in kvmppc_clear_host_ipi()
*/
smp_mb();
- paca_ptrs[cpu]->kvm_hstate.host_ipi = 1;
+ WRITE_ONCE(paca_ptrs[cpu]->kvm_hstate.host_ipi, 1);
}
static inline void kvmppc_clear_host_ipi(int cpu)
{
- paca_ptrs[cpu]->kvm_hstate.host_ipi = 0;
+ WRITE_ONCE(paca_ptrs[cpu]->kvm_hstate.host_ipi, 0);
/*
* order clearing of host_ipi flag vs. processing of IPI messages
*
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index da85f046377a..0f5b021fa559 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -406,7 +406,7 @@ static long kvmppc_read_one_intr(bool *again)
return 1;
/* see if a host IPI is pending */
- host_ipi = local_paca->kvm_hstate.host_ipi;
+ host_ipi = READ_ONCE(local_paca->kvm_hstate.host_ipi);
if (host_ipi)
return 1;
@@ -466,7 +466,7 @@ static long kvmppc_read_one_intr(bool *again)
* meantime. If it's clear, we bounce the interrupt to the
* guest
*/
- host_ipi = local_paca->kvm_hstate.host_ipi;
+ host_ipi = READ_ONCE(local_paca->kvm_hstate.host_ipi);
if (unlikely(host_ipi != 0)) {
/* We raced with the host,
* we need to resend that IPI, bummer
--
2.37.2
[PATCH v2 03/11] asm-generic/mmiowb: Mark accesses to fix KCSAN warnings
Prior to this patch, data races are detectable by KCSAN of the following
forms:
[1] Asynchronous calls to mmiowb_set_pending() from an interrupt context
or otherwise outside of a critical section
[2] Interrupted critical sections, where the interrupt will itself
acquire a lock
In case [1], calling context does not need an mmiowb() call to be
issued, otherwise it would do so itself. Such calls to
mmiowb_set_pending() are either idempotent or no-ops.
In case [2], irrespective of when the interrupt occurs, the interrupt
will acquire and release its locks prior to its return, nesting_count
will continue balanced. In the worst case, the interrupted critical
section during a mmiowb_spin_unlock() call observes an mmiowb to be
pending and afterward is interrupted, leading to an extraneous call to
mmiowb(). This data race is clearly innocuous.
Mark all potentially asynchronous memory accesses with READ_ONCE or
WRITE_ONCE, including increments and decrements to nesting_count. This
has the effect of removing KCSAN warnings at consumer's callsites.
Signed-off-by: Rohan McLure
Reported-by: Michael Ellerman
Reported-by: Gautam Menghani
Tested-by: Gautam Menghani
Acked-by: Arnd Bergmann
---
v2: Remove extraneous READ_ONCE in mmiowb_set_pending for nesting_count
---
include/asm-generic/mmiowb.h | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/asm-generic/mmiowb.h b/include/asm-generic/mmiowb.h
index 5698fca3bf56..6dea28c8835b 100644
--- a/include/asm-generic/mmiowb.h
+++ b/include/asm-generic/mmiowb.h
@@ -37,25 +37,29 @@ static inline void mmiowb_set_pending(void)
struct mmiowb_state *ms = __mmiowb_state();
if (likely(ms->nesting_count))
- ms->mmiowb_pending = ms->nesting_count;
+ WRITE_ONCE(ms->mmiowb_pending, ms->nesting_count);
}
static inline void mmiowb_spin_lock(void)
{
struct mmiowb_state *ms = __mmiowb_state();
- ms->nesting_count++;
+
+ /* Increment need not be atomic. Nestedness is balanced over
interrupts. */
+ WRITE_ONCE(ms->nesting_count, READ_ONCE(ms->nesting_count) + 1);
}
static inline void mmiowb_spin_unlock(void)
{
struct mmiowb_state *ms = __mmiowb_state();
+ u16 pending = READ_ONCE(ms->mmiowb_pending);
- if (unlikely(ms->mmiowb_pending)) {
- ms->mmiowb_pending = 0;
+ WRITE_ONCE(ms->mmiowb_pending, 0);
+ if (unlikely(pending)) {
mmiowb();
}
- ms->nesting_count--;
+ /* Decrement need not be atomic. Nestedness is balanced over
interrupts. */
+ WRITE_ONCE(ms->nesting_count, READ_ONCE(ms->nesting_count) - 1);
}
#else
#define mmiowb_set_pending() do { } while (0)
--
2.37.2
[PATCH v2 07/11] powerpc: Annotate accesses to ipi message flags
IPI message flags are observed and consequently consumed in the smp_ipi_demux_relaxed function, which handles these message sources until it observes none more arriving. Mark the checked loop guard with READ_ONCE, to signal to KCSAN that the read is known to be volatile, and that non-determinism is expected. Mark write for message source in smp_muxed_ipi_set_message(). Signed-off-by: Rohan McLure --- v2: Add missing WRITE_ONCE() in smp_muxed_ipi_set_message(). --- arch/powerpc/kernel/smp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c index 6b90f10a6c81..fb35a147b4fa 100644 --- a/arch/powerpc/kernel/smp.c +++ b/arch/powerpc/kernel/smp.c @@ -289,7 +289,7 @@ void smp_muxed_ipi_set_message(int cpu, int msg) * Order previous accesses before accesses in the IPI handler. */ smp_mb(); - message[msg] = 1; + WRITE_ONCE(message[msg], 1); } void smp_muxed_ipi_message_pass(int cpu, int msg) @@ -348,7 +348,7 @@ irqreturn_t smp_ipi_demux_relaxed(void) if (all & IPI_MESSAGE(PPC_MSG_NMI_IPI)) nmi_ipi_action(0, NULL); #endif - } while (info->messages); + } while (READ_ONCE(info->messages)); return IRQ_HANDLED; } -- 2.37.2
[PATCH v2 06/11] powerpc: powernv: Fix KCSAN datarace warnings on idle_state contention
The idle_state entry in the PACA on PowerNV features a bit which is
atomically tested and set through ldarx/stdcx. to be used as a spinlock.
This lock then guards access to other bit fields of idle_state. KCSAN
cannot differentiate between any of these bitfield accesses as they all
are implemented by 8-byte store/load instructions, thus cores contending
on the bit-lock appear to data race with modifications to idle_state.
Separate the bit-lock entry from the data guarded by the lock to avoid
the possibility of data races being detected by KCSAN.
Suggested-by: Nicholas Piggin
Signed-off-by: Rohan McLure
---
v2: Remove extraneous WRITE_ONCE on paca thread_idle_state, which are
only read diagnostically.
---
arch/powerpc/include/asm/paca.h | 1 +
arch/powerpc/platforms/powernv/idle.c | 16 +---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index da0377f46597..cb325938766a 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -191,6 +191,7 @@ struct paca_struct {
#ifdef CONFIG_PPC_POWERNV
/* PowerNV idle fields */
/* PNV_CORE_IDLE_* bits, all siblings work on thread 0 paca */
+ unsigned long idle_lock; /* A value of 1 means acquired */
unsigned long idle_state;
union {
/* P7/P8 specific fields */
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
index 841cb7f31f4f..c1e0ecb014a5 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -246,9 +246,9 @@ static inline void atomic_lock_thread_idle(void)
{
int cpu = raw_smp_processor_id();
int first = cpu_first_thread_sibling(cpu);
- unsigned long *state = _ptrs[first]->idle_state;
+ unsigned long *lock = _ptrs[first]->idle_lock;
- while (unlikely(test_and_set_bit_lock(NR_PNV_CORE_IDLE_LOCK_BIT,
state)))
+ while (unlikely(test_and_set_bit_lock(NR_PNV_CORE_IDLE_LOCK_BIT, lock)))
barrier();
}
@@ -258,29 +258,31 @@ static inline void
atomic_unlock_and_stop_thread_idle(void)
int first = cpu_first_thread_sibling(cpu);
unsigned long thread = 1UL << cpu_thread_in_core(cpu);
unsigned long *state = _ptrs[first]->idle_state;
+ unsigned long *lock = _ptrs[first]->idle_lock;
u64 s = READ_ONCE(*state);
u64 new, tmp;
- BUG_ON(!(s & PNV_CORE_IDLE_LOCK_BIT));
+ BUG_ON(!(READ_ONCE(*lock) & PNV_CORE_IDLE_LOCK_BIT));
BUG_ON(s & thread);
again:
- new = (s | thread) & ~PNV_CORE_IDLE_LOCK_BIT;
+ new = s | thread;
tmp = cmpxchg(state, s, new);
if (unlikely(tmp != s)) {
s = tmp;
goto again;
}
+ clear_bit_unlock(NR_PNV_CORE_IDLE_LOCK_BIT, lock);
}
static inline void atomic_unlock_thread_idle(void)
{
int cpu = raw_smp_processor_id();
int first = cpu_first_thread_sibling(cpu);
- unsigned long *state = _ptrs[first]->idle_state;
+ unsigned long *lock = _ptrs[first]->idle_lock;
- BUG_ON(!test_bit(NR_PNV_CORE_IDLE_LOCK_BIT, state));
- clear_bit_unlock(NR_PNV_CORE_IDLE_LOCK_BIT, state);
+ BUG_ON(!test_bit(NR_PNV_CORE_IDLE_LOCK_BIT, lock));
+ clear_bit_unlock(NR_PNV_CORE_IDLE_LOCK_BIT, lock);
}
/* P7 and P8 */
--
2.37.2
[PATCH v2 05/11] powerpc: Mark accesses to power_save callback in arch_cpu_idle
The power_save callback can be overwritten by another core at boot time.
Specifically, null values will be replaced exactly once with the callback
suitable for the particular platform (PowerNV / pseries lpars), making
this value a good candidate for __ro_after_init.
Even with this the case, KCSAN sees unmarked reads to the callback
variable, and notices that unfortunate compiler reorderings could lead
to distinct function pointers being read. In reality this is impossible,
so don't instrument at this read.
Signed-off-by: Rohan McLure
---
v2: Mark instances at init where the callback is written to, and
data_race() read as there is no capacity for the value to change
underneath.
---
arch/powerpc/kernel/idle.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index b1c0418b25c8..43d96c0e3b96 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -35,7 +35,7 @@ EXPORT_SYMBOL(cpuidle_disable);
static int __init powersave_off(char *arg)
{
- ppc_md.power_save = NULL;
+ WRITE_ONCE(ppc_md.power_save, NULL);
cpuidle_disable = IDLE_POWERSAVE_OFF;
return 1;
}
@@ -43,10 +43,13 @@ __setup("powersave=off", powersave_off);
void arch_cpu_idle(void)
{
+ /* power_save callback assigned only at init so no data race */
+ void (*power_save)(void) = data_race(ppc_md.power_save);
+
ppc64_runlatch_off();
- if (ppc_md.power_save) {
- ppc_md.power_save();
+ if (power_save) {
+ power_save();
/*
* Some power_save functions return with
* interrupts enabled, some don't.
--
2.37.2
[PATCH v2 01/11] powerpc: qspinlock: Mark accesses to qnode lock checks
The powerpc implemenation of qspinlocks will both poll and spin on the
bitlock guarding a qnode. Mark these accesses with READ_ONCE to convey
to KCSAN that polling is intentional here.
Signed-off-by: Rohan McLure
Reviewed-by: Nicholas Piggin
---
arch/powerpc/lib/qspinlock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/lib/qspinlock.c b/arch/powerpc/lib/qspinlock.c
index e4bd145255d0..b76c1f6acce5 100644
--- a/arch/powerpc/lib/qspinlock.c
+++ b/arch/powerpc/lib/qspinlock.c
@@ -435,7 +435,7 @@ static __always_inline bool yield_to_prev(struct qspinlock
*lock, struct qnode *
smp_rmb(); /* See __yield_to_locked_owner comment */
- if (!node->locked) {
+ if (!READ_ONCE(node->locked)) {
yield_to_preempted(prev_cpu, yield_count);
spin_begin();
return preempted;
@@ -584,7 +584,7 @@ static __always_inline void
queued_spin_lock_mcs_queue(struct qspinlock *lock, b
/* Wait for mcs node lock to be released */
spin_begin();
- while (!node->locked) {
+ while (!READ_ONCE(node->locked)) {
spec_barrier();
if (yield_to_prev(lock, node, old, paravirt))
--
2.37.2
[PATCH v2 10/11] powerpc: powernv: Annotate asynchronous access to opal tokens
The opal-async.c unit contains code for polling event sources, which
implies intentional data races. Ensure that the compiler will atomically
access such variables by means of {READ,WRITE}_ONCE calls, which in turn
inform KCSAN that polling behaviour is intended.
Signed-off-by: Rohan McLure
---
arch/powerpc/platforms/powernv/opal-async.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-async.c
b/arch/powerpc/platforms/powernv/opal-async.c
index c094fdf5825c..282d2ac6fbb0 100644
--- a/arch/powerpc/platforms/powernv/opal-async.c
+++ b/arch/powerpc/platforms/powernv/opal-async.c
@@ -146,7 +146,7 @@ int opal_async_wait_response(uint64_t token, struct
opal_msg *msg)
* functional.
*/
opal_wake_poller();
- wait_event(opal_async_wait, opal_async_tokens[token].state
+ wait_event(opal_async_wait, READ_ONCE(opal_async_tokens[token].state)
== ASYNC_TOKEN_COMPLETED);
memcpy(msg, _async_tokens[token].response, sizeof(*msg));
@@ -185,7 +185,7 @@ int opal_async_wait_response_interruptible(uint64_t token,
struct opal_msg *msg)
* interruptible version before doing anything else with the
* token.
*/
- if (opal_async_tokens[token].state == ASYNC_TOKEN_ALLOCATED) {
+ if (READ_ONCE(opal_async_tokens[token].state) == ASYNC_TOKEN_ALLOCATED)
{
spin_lock_irqsave(_async_comp_lock, flags);
if (opal_async_tokens[token].state == ASYNC_TOKEN_ALLOCATED)
opal_async_tokens[token].state = ASYNC_TOKEN_DISPATCHED;
@@ -199,7 +199,7 @@ int opal_async_wait_response_interruptible(uint64_t token,
struct opal_msg *msg)
*/
opal_wake_poller();
ret = wait_event_interruptible(opal_async_wait,
- opal_async_tokens[token].state ==
+ READ_ONCE(opal_async_tokens[token].state) ==
ASYNC_TOKEN_COMPLETED);
if (!ret)
memcpy(msg, _async_tokens[token].response, sizeof(*msg));
--
2.37.2
[PATCH v2 02/11] powerpc: qspinlock: Enforce qnode writes prior to publishing to queue
Annotate the release barrier and memory clobber (in effect, producing a
compiler barrier) in the publish_tail_cpu call. These barriers have the
effect of ensuring that qnode attributes are all written to prior to
publish the node to the waitqueue.
Even while the initial write to the 'locked' attribute is guaranteed to
terminate prior to the node being visible, KCSAN still complains that
the write is reorderable by the compiler. Issue a kcsan_release() to
inform KCSAN of the release barrier contained in publish_tail_cpu().
Signed-off-by: Rohan McLure
---
v2: Remove extraneous compiler barrier, but annotate release-barrier
contained in call publish_tail_cpu(), and include kcsan_release().
---
arch/powerpc/lib/qspinlock.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/lib/qspinlock.c b/arch/powerpc/lib/qspinlock.c
index b76c1f6acce5..253620979d0c 100644
--- a/arch/powerpc/lib/qspinlock.c
+++ b/arch/powerpc/lib/qspinlock.c
@@ -161,6 +161,8 @@ static __always_inline u32 publish_tail_cpu(struct
qspinlock *lock, u32 tail)
{
u32 prev, tmp;
+ kcsan_release();
+
asm volatile(
"\t" PPC_RELEASE_BARRIER " \n"
"1:lwarx %0,0,%2 # publish_tail_cpu \n"
@@ -570,6 +572,11 @@ static __always_inline void
queued_spin_lock_mcs_queue(struct qspinlock *lock, b
tail = encode_tail_cpu(node->cpu);
+ /*
+* Assign all attributes of a node before it can be published.
+* Issues an lwsync, serving as a release barrier, as well as a
+* compiler barrier.
+*/
old = publish_tail_cpu(lock, tail);
/*
--
2.37.2
[PATCH v2 00/11] powerpc: KCSAN fix warnings and mark accesses
v1 of this patch series available here: Link: https://lore.kernel.org/linuxppc-dev/20230508020120.218494-1-rmcl...@linux.ibm.com/ The KCSAN sanitiser notifies programmers of instances where unmarked accesses to shared state has lead to a data race, or when the compiler has liberty to reorder an unmarked access and so generate a data race. This patch series deals with benign data races, which nonetheless need annotation in order to ensure the correctness of the emitted code. In keeping with the principles given in tools/memory-model/Documentation/access-marking.txt, racing reads of shared state for purely diagnostic/debug purposes are annotated with data_race, while reads/writes that are examples of intention polling of shared variables are performed with READ_ONCE, WRITE_ONCE. These changes remove the majority of warnings observable on pseries and powernv, where for development, I was able to narrow down to only power relevant bugs by temporarily disabling sanitisation for all other files. Future patch series will deal with the subtler bugs which persist under this configuration. KCSAN races addressed: - qspinlock: assignign of qnode->locked and polling - check_return_regs_valid [h]srr_valid - arch_cpu_idle idle callback - powernv idle_state paca entry (polling the bit-lock is viewed by KCSAN as asynchronous access to the fields it protects) - Asynchronous access to irq_data->hwirq - Opal asynchronous event handling - IPIs Miscellaneous other changes: - Annotate the asm-generic/mmiowb code, which riscv and powerpc each consume - Update usages of qnode->locked in powerpc's qspinlock interpretation to reflect the comment beside this field v2: - Match READ_ONCE with WRITE_ONCE and vice versa where required - In arch/powerpc/lib/qspinlock.c, use kcsan_release() to notify KCSAN of locked being assigned prior to publish, and remove extraneous compiler barrier (publish_tail_cpu features memory clobber). - Keep polarity for locked variable in qspinlock - Remove extraneous READ_ONCE in mmiowb() - Use data_race() for power_save callback to remove instrumentation, as there is no real data race Rohan McLure (11): powerpc: qspinlock: Mark accesses to qnode lock checks powerpc: qspinlock: Enforce qnode writes prior to publishing to queue asm-generic/mmiowb: Mark accesses to fix KCSAN warnings powerpc: Mark [h]ssr_valid accesses in check_return_regs_valid powerpc: Mark accesses to power_save callback in arch_cpu_idle powerpc: powernv: Fix KCSAN datarace warnings on idle_state contention powerpc: Annotate accesses to ipi message flags powerpc: Mark writes registering ipi to host cpu through kvm and polling powerpc: powernv: Annotate data races in opal events powerpc: powernv: Annotate asynchronous access to opal tokens powerpc: Mark asynchronous accesses to irq_data arch/powerpc/include/asm/kvm_ppc.h| 4 ++-- arch/powerpc/include/asm/paca.h | 1 + arch/powerpc/include/asm/ptrace.h | 4 ++-- arch/powerpc/kernel/idle.c| 9 ++--- arch/powerpc/kernel/interrupt.c | 14 ++ arch/powerpc/kernel/irq.c | 2 +- arch/powerpc/kernel/smp.c | 4 ++-- arch/powerpc/kvm/book3s_hv_builtin.c | 4 ++-- arch/powerpc/lib/qspinlock.c | 11 +-- arch/powerpc/platforms/powernv/idle.c | 16 +--- arch/powerpc/platforms/powernv/opal-async.c | 6 +++--- arch/powerpc/platforms/powernv/opal-irqchip.c | 6 +++--- arch/powerpc/platforms/powernv/pci-ioda.c | 12 ++-- include/asm-generic/mmiowb.h | 14 +- include/linux/irq.h | 2 +- kernel/irq/irqdomain.c| 4 ++-- 16 files changed, 64 insertions(+), 49 deletions(-) -- 2.37.2
Re: linux-next: boot warning
Hi Tejun, On Tue, 9 May 2023 05:33:02 -1000 Tejun Heo wrote: > > On Tue, May 09, 2023 at 05:09:43PM +1000, Michael Ellerman wrote: > > Stephen Rothwell writes: > > > Hi all, > > > > > > Today's qemu test boot (powerpc pseries_le_defconfig) produced this > > > warning: > > > > > > [2.048588][T1] ipr: IBM Power RAID SCSI Device Driver version: > > > 2.6.4 (March 14, 2017) > > > [2.051560][T1] [ cut here ] > > > [2.052297][T1] WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:5925 > > > workqueue_sysfs_register+0x20/0x1f0 > > > > Caused by 59709bb84c22 scsi: Use alloc_ordered_workqueue() to create > > ordered workqueues. > > The patch is already dropped. It was applied only for a short window > yesterday. Should be okay now. Confirmed, the warning is gone. -- Cheers, Stephen Rothwell pgpfSK5OzsTfI.pgp Description: OpenPGP digital signature
Re: [PATCH 07/12] powerpc: powernv: Fix KCSAN datarace warnings on idle_state contention
> On 9 May 2023, at 12:26 pm, Nicholas Piggin wrote:
>
> On Mon May 8, 2023 at 12:01 PM AEST, Rohan McLure wrote:
>> The idle_state entry in the PACA on PowerNV features a bit which is
>> atomically tested and set through ldarx/stdcx. to be used as a spinlock.
>> This lock then guards access to other bit fields of idle_state. KCSAN
>> cannot differentiate between any of these bitfield accesses as they all
>> are implemented by 8-byte store/load instructions, thus cores contending
>> on the bit-lock appear to data race with modifications to idle_state.
>>
>> Separate the bit-lock entry from the data guarded by the lock to avoid
>> the possibility of data races being detected by KCSAN.
>>
>> Suggested-by: Nicholas Piggin
>> Signed-off-by: Rohan McLure
>> ---
>> arch/powerpc/include/asm/paca.h | 1 +
>> arch/powerpc/platforms/powernv/idle.c | 20 +++-
>> 2 files changed, 12 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/paca.h
>> b/arch/powerpc/include/asm/paca.h
>> index da0377f46597..cb325938766a 100644
>> --- a/arch/powerpc/include/asm/paca.h
>> +++ b/arch/powerpc/include/asm/paca.h
>> @@ -191,6 +191,7 @@ struct paca_struct {
>> #ifdef CONFIG_PPC_POWERNV
>> /* PowerNV idle fields */
>> /* PNV_CORE_IDLE_* bits, all siblings work on thread 0 paca */
>> + unsigned long idle_lock; /* A value of 1 means acquired */
>> unsigned long idle_state;
>> union {
>> /* P7/P8 specific fields */
>> diff --git a/arch/powerpc/platforms/powernv/idle.c
>> b/arch/powerpc/platforms/powernv/idle.c
>> index 841cb7f31f4f..97dbb7bc2b00 100644
>> --- a/arch/powerpc/platforms/powernv/idle.c
>> +++ b/arch/powerpc/platforms/powernv/idle.c
>> @@ -246,9 +246,9 @@ static inline void atomic_lock_thread_idle(void)
>> {
>> int cpu = raw_smp_processor_id();
>> int first = cpu_first_thread_sibling(cpu);
>> - unsigned long *state = _ptrs[first]->idle_state;
>> + unsigned long *lock = _ptrs[first]->idle_lock;
>>
>> - while (unlikely(test_and_set_bit_lock(NR_PNV_CORE_IDLE_LOCK_BIT, state)))
>> + while (unlikely(test_and_set_bit_lock(NR_PNV_CORE_IDLE_LOCK_BIT, lock)))
>> barrier();
>> }
>>
>> @@ -258,29 +258,31 @@ static inline void
>> atomic_unlock_and_stop_thread_idle(void)
>> int first = cpu_first_thread_sibling(cpu);
>> unsigned long thread = 1UL << cpu_thread_in_core(cpu);
>> unsigned long *state = _ptrs[first]->idle_state;
>> + unsigned long *lock = _ptrs[first]->idle_lock;
>> u64 s = READ_ONCE(*state);
>> u64 new, tmp;
>>
>> - BUG_ON(!(s & PNV_CORE_IDLE_LOCK_BIT));
>> + BUG_ON(!(READ_ONCE(*lock) & PNV_CORE_IDLE_LOCK_BIT));
>> BUG_ON(s & thread);
>>
>> again:
>> - new = (s | thread) & ~PNV_CORE_IDLE_LOCK_BIT;
>> + new = s | thread;
>> tmp = cmpxchg(state, s, new);
>> if (unlikely(tmp != s)) {
>> s = tmp;
>> goto again;
>> }
>> + clear_bit_unlock(NR_PNV_CORE_IDLE_LOCK_BIT, lock);
>
> Sigh, another atomic. It's in a slow path though so I won't get too
> upset. Would be nice to add a comment here and revert it when KCSCAN
> can be taught about this pattern though, so we don't lose it.
>
>> }
>>
>> static inline void atomic_unlock_thread_idle(void)
>> {
>> int cpu = raw_smp_processor_id();
>> int first = cpu_first_thread_sibling(cpu);
>> - unsigned long *state = _ptrs[first]->idle_state;
>> + unsigned long *lock = _ptrs[first]->idle_lock;
>>
>> - BUG_ON(!test_bit(NR_PNV_CORE_IDLE_LOCK_BIT, state));
>> - clear_bit_unlock(NR_PNV_CORE_IDLE_LOCK_BIT, state);
>> + BUG_ON(!test_bit(NR_PNV_CORE_IDLE_LOCK_BIT, lock));
>> + clear_bit_unlock(NR_PNV_CORE_IDLE_LOCK_BIT, lock);
>> }
>>
>> /* P7 and P8 */
>> @@ -380,9 +382,9 @@ static unsigned long power7_idle_insn(unsigned long type)
>> sprs.uamor = mfspr(SPRN_UAMOR);
>> }
>>
>> - local_paca->thread_idle_state = type;
>> + WRITE_ONCE(local_paca->thread_idle_state, type);
>> srr1 = isa206_idle_insn_mayloss(type); /* go idle */
>> - local_paca->thread_idle_state = PNV_THREAD_RUNNING;
>> + WRITE_ONCE(local_paca->thread_idle_state, PNV_THREAD_RUNNING);
>
> Where is the thread_idle_state concurrency coming from?
Yeah, I agree, WRITE_ONCE isn’t necessary here, as all reads of this variable
by xmon are purely diagnostic (data races permitted), and the
isa206_idle_insn_mayloss() call is a compiler barrier. So write instructions
will be emitted on each side of the call.
>
> Thanks,
> Nick
[PATCH] powerpc/iommu: limit number of TCEs to 512 for H_STUFF_TCE hcall
As of now, in tce_freemulti_pSeriesLP(), there is no limit on how many TCEs
are passed to H_STUFF_TCE hcall. PAPR is enforcing this to be limited to
512 TCEs.
Signed-off-by: Gaurav Batra
Reviewed-by: Brian King
---
arch/powerpc/platforms/pseries/iommu.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index c74b71d4733d..1b134b1b795a 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -306,13 +306,21 @@ static void tce_free_pSeriesLP(unsigned long liobn, long
tcenum, long tceshift,
static void tce_freemulti_pSeriesLP(struct iommu_table *tbl, long tcenum, long
npages)
{
u64 rc;
+ long limit, rpages = npages;
if (!firmware_has_feature(FW_FEATURE_STUFF_TCE))
return tce_free_pSeriesLP(tbl->it_index, tcenum,
tbl->it_page_shift, npages);
- rc = plpar_tce_stuff((u64)tbl->it_index,
-(u64)tcenum << tbl->it_page_shift, 0, npages);
+ do {
+ limit = min_t(long, rpages, 512);
+
+ rc = plpar_tce_stuff((u64)tbl->it_index,
+ (u64)tcenum << tbl->it_page_shift, 0, limit);
+
+ rpages -= limit;
+ tcenum += limit;
+ } while (rpages > 0 && !rc);
if (rc && printk_ratelimit()) {
printk("tce_freemulti_pSeriesLP: plpar_tce_stuff failed\n");
--
Re: [PATCH v2 0/4] KVM: Refactor KVM stats macros and enable custom stat names
On Mon, Mar 6, 2023 at 11:01 AM David Matlack wrote: > > This series refactors the KVM stats macros to reduce duplication and > adds the support for choosing custom names for stats. Hi Paolo, I just wanted to double-check if this series is on your radar (probably for 6.5)?
Re: [PATCH v8 1/3] riscv: Introduce CONFIG_RELOCATABLE
On 5/9/23 21:07, Andreas Schwab wrote: That does not work with UEFI booting: Loading Linux 6.4.0-rc1-1.g668187d-default ... Loading initial ramdisk ... Unhandled exception: Instruction access fault EPC: 80016d56 RA: 8020334e TVAL: 007f80016d56 EPC: 002d1d56 RA: 004be34e reloc adjusted Unhandled exception: Load access fault EPC: fff462d4 RA: fff462d0 TVAL: 80016d56 EPC: 802012d4 RA: 802012d0 reloc adjusted Code: c825 8e0d 05b3 40b4 d0ef 0636 7493 ffe4 (d783 0004) UEFI image [0xfe65e000:0xfe6e3fff] '/efi\boot\bootriscv64.efi' UEFI image [0xdaa82000:0xdcc2afff] I need more details please, as I have a UEFI bootflow and it works great (KASLR is based on a relocatable kernel and works fine in UEFI too). Thanks, Alex
Re: [EXT] Re: [PATCH v2 1/1] PCI: layerscape: Add the endpoint linkup notifier support
On Mon, May 08, 2023 at 09:45:59PM +, Frank Li wrote: > > > > Subject: [EXT] Re: [PATCH v2 1/1] PCI: layerscape: Add the endpoint > > linkup > > > > notifier support > > > > All these quoted headers are redundant clutter since we've already > > seen them when Manivannan sent his comments. It would be nice if your > > mailer could be configured to omit them. > > Our email client quite stupid. Yeah, sometimes those are really hard to work around. Bjorn
Re: [PATCH v8 1/3] riscv: Introduce CONFIG_RELOCATABLE
That does not work with UEFI booting: Loading Linux 6.4.0-rc1-1.g668187d-default ... Loading initial ramdisk ... Unhandled exception: Instruction access fault EPC: 80016d56 RA: 8020334e TVAL: 007f80016d56 EPC: 002d1d56 RA: 004be34e reloc adjusted Unhandled exception: Load access fault EPC: fff462d4 RA: fff462d0 TVAL: 80016d56 EPC: 802012d4 RA: 802012d0 reloc adjusted Code: c825 8e0d 05b3 40b4 d0ef 0636 7493 ffe4 (d783 0004) UEFI image [0xfe65e000:0xfe6e3fff] '/efi\boot\bootriscv64.efi' UEFI image [0xdaa82000:0xdcc2afff] -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH v8 0/7] Add pci_dev_for_each_resource() helper and update users
On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> > Provide two new helper macros to iterate over PCI device resources and
> > convert users.
> Applied 2-7 to pci/resource for v6.4, thanks, I really like this!
This is 09cc90063240 ("PCI: Introduce pci_dev_for_each_resource()")
upstream now.
Coverity complains about each use, sample below from
drivers/pci/vgaarb.c. I didn't investigate at all, so it might be a
false positive; just FYI.
1. Condition screen_info.capabilities & (2U /* 1 << 1 */), taking
true branch.
556if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
557base |= (u64)screen_info.ext_lfb_base << 32;
558
559limit = base + size;
560
561/* Does firmware framebuffer belong to us? */
2. Condition __b < PCI_NUM_RESOURCES, taking true branch.
3. Condition (r = >resource[__b]) , (__b < PCI_NUM_RESOURCES),
taking true branch.
6. Condition __b < PCI_NUM_RESOURCES, taking true branch.
7. cond_at_most: Checking __b < PCI_NUM_RESOURCES implies that __b
may be up to 16 on the true branch.
8. Condition (r = >resource[__b]) , (__b < PCI_NUM_RESOURCES),
taking true branch.
11. incr: Incrementing __b. The value of __b may now be up to 17.
12. alias: Assigning: r = >resource[__b]. r may now point to as
high as element 17 of pdev->resource (which consists of 17 64-byte elements).
13. Condition __b < PCI_NUM_RESOURCES, taking true branch.
14. Condition (r = >resource[__b]) , (__b < PCI_NUM_RESOURCES),
taking true branch.
562pci_dev_for_each_resource(pdev, r) {
4. Condition resource_type(r) != 512, taking true branch.
9. Condition resource_type(r) != 512, taking true branch.
CID 1529911 (#1 of 1): Out-of-bounds read (OVERRUN)
15. overrun-local: Overrunning array of 1088 bytes at byte offset 1088 by
dereferencing pointer r. [show details]
563if (resource_type(r) != IORESOURCE_MEM)
5. Continuing loop.
10. Continuing loop.
564continue;
Re: [PATCH] powerpc/64: Use -mprofile-kernel for big endian ELFv2 kernels
Nicholas Piggin wrote:
-mprofile-kernel is an optimised calling convention for mcount that
Linux has only implemented with the ELFv2 ABI, so it was disabled for
big endian kernels. However it does work with ELFv2 big endian, so let's
allow that if the compiler supports it.
Cc: Naveen N. Rao
Suggested-by: Christophe Leroy
Signed-off-by: Nicholas Piggin
---
Christophe had the good idea that we could use -mprofile-kernel for
ELFv2 BE. Unfortunately can't remove -pg due to lack of -mprofile-kernel
in clang, but this gives BE the nicer ftrace code with GCC at least.
Function tracer works for me with a BE kernel.
LGTM. With a few minor nits below:
Acked-by: Naveen N. Rao
Thanks,
Nick
arch/powerpc/Kconfig| 6 --
arch/powerpc/tools/gcc-check-mprofile-kernel.sh | 4 ++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a64bfd9b8a1d..bd2ee7af1342 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -547,8 +547,10 @@ config LD_HEAD_STUB_CATCH
If unsure, say "N".
config MPROFILE_KERNEL
- depends on PPC64 && CPU_LITTLE_ENDIAN && FUNCTION_TRACER
- def_bool
$(success,$(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC)
-I$(srctree)/include -D__KERNEL__)
+ depends on PPC64 && FUNCTION_TRACER
+ depends on CPU_LITTLE_ENDIAN || PPC64_BIG_ENDIAN_ELF_ABI_V2
Can't we just check for PPC64_ELF_ABI_V2?
+ def_bool
$(success,$(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC)
-mlittle-endian) if CPU_LITTLE_ENDIAN
+ def_bool
$(success,$(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC)
-mbig-endian) if CPU_BIG_ENDIAN
config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
diff --git a/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
b/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
index 137f3376ac2b..e78c599251ff 100755
--- a/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
+++ b/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
@@ -14,13 +14,13 @@ set -o pipefail
We have this comment before the below code, which should also be
updated/removed:
# -mprofile-kernel is only supported on 64le, so this should not be invoked
# for other targets. Therefore we can pass in -m64 and -mlittle-endian
# explicitly, to take care of toolchains defaulting to other targets.
# Test whether the compile option -mprofile-kernel exists and generates
# profiling code (ie. a call to _mcount()).
echo "int func() { return 0; }" | \
-$* -m64 -mlittle-endian -S -x c -O2 -p -mprofile-kernel - -o - \
+$* -m64 -S -x c -O2 -p -mprofile-kernel - -o - \
2> /dev/null | grep -q "_mcount"
# Test whether the notrace attribute correctly suppresses calls to _mcount().
echo -e "#include \nnotrace int func() { return 0; }" | \
-$* -m64 -mlittle-endian -S -x c -O2 -p -mprofile-kernel - -o - \
+$* -m64 -S -x c -O2 -p -mprofile-kernel - -o - \
2> /dev/null | grep -q "_mcount" && \
exit 1
- Naveen
Re: linux-next: boot warning
On Tue, May 09, 2023 at 05:09:43PM +1000, Michael Ellerman wrote: > Stephen Rothwell writes: > > Hi all, > > > > Today's qemu test boot (powerpc pseries_le_defconfig) produced this > > warning: > > > > [2.048588][T1] ipr: IBM Power RAID SCSI Device Driver version: > > 2.6.4 (March 14, 2017) > > [2.051560][T1] [ cut here ] > > [2.052297][T1] WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:5925 > > workqueue_sysfs_register+0x20/0x1f0 > > Caused by 59709bb84c22 scsi: Use alloc_ordered_workqueue() to create ordered > workqueues. The patch is already dropped. It was applied only for a short window yesterday. Should be okay now. Thanks. -- tejun
Re: [PATCH v14 06/15] clk: Add Lynx 10G SerDes PLL driver
On 5/9/23 09:00, Vinod Koul wrote: > On 08-05-23, 11:31, Sean Anderson wrote: >> On 5/8/23 05:15, Vinod Koul wrote: > >> >> +int lynx_clks_init(struct device *dev, struct regmap *regmap, >> >> +struct clk *plls[2], struct clk *ex_dlys[2], bool compat); >> > >> > so you have an exported symbol for clk driver init in phy driver header? >> > can you please explain why..? >> >> So that it can be called at the appropriate time during the phy's probe >> function. >> >> This is really an integral part of the phy driver, but I was directed to >> split it >> off and put it in another subsystem's directory. > > That is right clock should be belong to clk driver. IIUC the hardware is > phy along with clocks and you are doing the clk init. I think that may > not be correct model, you should really have a device tree node to > represent the clock and the phy node > > > What stops this from being modelled as it is in the hardware? It *is* modeled as it is in hardware. With just the serdes compatible, we have all the information we need to create the clocks. So we do so. There's no need for a separate device just to create four clocks. These clocks cannot be used by any other device (except possibly by putting a lane into test mode). So there is no benefit from making them a separate device, except an increase in complexity due to ordering and dynamic lookup. By doing things this way we know that either there was an error or the clocks all exist, and the lifetime of the clocks matches the serdes. --Sean
Re: [PATCH v14 06/15] clk: Add Lynx 10G SerDes PLL driver
On 08-05-23, 11:31, Sean Anderson wrote: > On 5/8/23 05:15, Vinod Koul wrote: > >> +int lynx_clks_init(struct device *dev, struct regmap *regmap, > >> + struct clk *plls[2], struct clk *ex_dlys[2], bool compat); > > > > so you have an exported symbol for clk driver init in phy driver header? > > can you please explain why..? > > So that it can be called at the appropriate time during the phy's probe > function. > > This is really an integral part of the phy driver, but I was directed to > split it > off and put it in another subsystem's directory. That is right clock should be belong to clk driver. IIUC the hardware is phy along with clocks and you are doing the clk init. I think that may not be correct model, you should really have a device tree node to represent the clock and the phy node What stops this from being modelled as it is in the hardware? -- ~Vinod
Re: [RFC PATCH] asm-generic: Unify uapi bitsperlong.h
On Tue, May 9, 2023, at 09:05, Tiezhu Yang wrote: > Now we specify the minimal version of GCC as 5.1 and Clang/LLVM as 11.0.0 > in Documentation/process/changes.rst, __CHAR_BIT__ and __SIZEOF_LONG__ are > usable, just define __BITS_PER_LONG as (__CHAR_BIT__ * __SIZEOF_LONG__) in > asm-generic uapi bitsperlong.h, simpler, works everywhere. > > Remove all the arch specific uapi bitsperlong.h which will be generated as > arch/*/include/generated/uapi/asm/bitsperlong.h. > > Suggested-by: Xi Ruoyao > Link: > https://lore.kernel.org/all/d3e255e4746de44c9903c4433616d44ffcf18d1b.ca...@xry111.site/ > Signed-off-by: Tiezhu Yang I originally introduced the bitsperlong.h header, and I'd love to see it removed if it's no longer needed. Your patch certainly seems like it does this well. There is one minor obstacle to this, which is that the compiler requirements for uapi headers are not the same as for kernel internal code. In particular, the uapi headers may be included by user space code that is built with an older compiler version, or with a compiler that is not gcc or clang. I think we are completely safe on the architectures that were added since the linux-3.x days (arm64, riscv, csky, openrisc, loongarch, nios2, and hexagon), but for the older ones there is a regression risk. Especially on targets that are not that actively maintained (sparc, alpha, ia64, sh, ...) there is a good chance that users are stuck on ancient toolchains. It's probably also a safe assumption that anyone with an older libc version won't be using the latest kernel headers, so I think we can still do this across architectures if both glibc and musl already require a compiler that is new enough, or alternatively if we know that the kernel headers require a new compiler for other reasons and nobody has complained. For glibc, it looks the minimum compiler version was raised from gcc-5 to gcc-8 four years ago, so we should be fine. In musl, the documentation states that at least gcc-3.4 or clang-3.2 are required, which probably predate the __SIZEOF_LONG__ macro. On the other hand, musl was only released in 2011, and building musl itself explicitly does not require kernel uapi headers, so this may not be too critical. There is also uClibc, but I could not find any minimum supported compiler version for that. Most commonly, this one is used for cross-build environments, so it's also less likely to have libc/gcc/headers being wildly out of sync. Not sure. Arnd [1] https://sourceware.org/pipermail/libc-alpha/2019-January/101010.html
[Bug 217350] kdump kernel hangs in powerkvm guest
https://bugzilla.kernel.org/show_bug.cgi?id=217350 Coiby (coiby...@gmail.com) changed: What|Removed |Added CC||c...@kaod.org, ||coiby...@gmail.com --- Comment #1 from Coiby (coiby...@gmail.com) --- Hi Cédric, My bisection [1] shows this is a regression caused by your patch it's a regression caused by "[PATCH 00/31] powerpc: Modernize the PCI/MSI support". Do you have any suggestion to fix this bug? Thanks! [1] https://bugzilla.redhat.com/show_bug.cgi?id=2123723 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 2/2] powerpc/pseries: Remove unused hcall tracing instruction
When JUMP_LABEL=n, the tracepoint refcount test in the pre-call stores
the refcount value to the stack, so the same value can be used for the
post-call (presumably to avoid racing with the value concurrently
changing).
On little-endian (ELFv2) that might have just worked by luck, because
32(r1) is STK_PARAM(R3) there and so the value save gets clobbered by
the tracing code when it's non-zero, but fortunately r3 is the hcall
number and 0 is an invalid hcall number so it should get clobbered by
another non-zero value. In any case, commit cc1adb5f32557
("powerpc/pseries: Use jump labels for hcall tracepoints") removed the
code that actually used the value stored, so now it's just dead code.
It's fragile to be storing to the stack like this, and confusing. Better
remove it.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/platforms/pseries/hvCall.S | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/hvCall.S
b/arch/powerpc/platforms/pseries/hvCall.S
index ca0674b0b683..bae45b358a09 100644
--- a/arch/powerpc/platforms/pseries/hvCall.S
+++ b/arch/powerpc/platforms/pseries/hvCall.S
@@ -92,7 +92,6 @@ BEGIN_FTR_SECTION;
\
END_FTR_SECTION(0, 1); \
LOAD_REG_ADDR(r12, hcall_tracepoint_refcount) ; \
ld r12,0(r12); \
- std r12,32(r1); \
cmpdi r12,0; \
bne-LABEL; \
1:
--
2.40.1
[PATCH 1/2] powerpc/pseries: Fix hcall tracepoints with JUMP_LABEL=n
With JUMP_LABEL=n, hcall_tracepoint_refcount's address is being tested
instead of its value. This results in the tracing slowpath always being
taken unnecessarily.
Fixes: 9a10ccb29c0a2 ("powerpc/pseries: move hcall_tracepoint_refcount out of
.toc")
Signed-off-by: Nicholas Piggin
---
arch/powerpc/platforms/pseries/hvCall.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/pseries/hvCall.S
b/arch/powerpc/platforms/pseries/hvCall.S
index 35254ac7af5e..ca0674b0b683 100644
--- a/arch/powerpc/platforms/pseries/hvCall.S
+++ b/arch/powerpc/platforms/pseries/hvCall.S
@@ -91,6 +91,7 @@ BEGIN_FTR_SECTION;
\
b 1f; \
END_FTR_SECTION(0, 1); \
LOAD_REG_ADDR(r12, hcall_tracepoint_refcount) ; \
+ ld r12,0(r12); \
std r12,32(r1); \
cmpdi r12,0; \
bne-LABEL; \
--
2.40.1
Re: [RFC PATCH 4/4] powerpc/64: Remove support for kernel's built with ELFv1 ABI
On Fri May 5, 2023 at 6:49 PM AEST, Christophe Leroy wrote: > > > Le 05/05/2023 à 09:18, Nicholas Piggin a écrit : > > User code must still support ELFv1, e.g., see is_elf2_task(). > > > > This one should wait a while until ELFv2 fallout settles, so > > just posting it out of interest. > > Can't ELFv1 user code run on an ELFv2 kernel ? Yes it can and that's what ELFv2 BE kernels do because most BE userspace is ELFv1 (although some are using ELFv2 BE). By ELFv2 fallout I mean bugs and toolchain problems that might get discovered after we flip the default. I think it would be good to keep the ELFv1 option around for a few releases to help testing such issues, the revert will probably pick up conflicts. Maybe that's being too paranoid. Thanks, Nick
Re: [PATCH] powerpc: Drop MPC5200 LocalPlus bus FIFO driver
Hello, On Thu, Apr 13, 2023 at 08:16:42AM +0200, Uwe Kleine-König wrote: > While mpc5200b.dtsi contains a device that this driver can bind to, the > only purpose of a bound device is to be used by the four exported functions > mpc52xx_lpbfifo_submit(), mpc52xx_lpbfifo_abort(), mpc52xx_lpbfifo_poll() > and mpc52xx_lpbfifo_start_xfer(). However there are no callers to this > function and so the driver is effectively superfluous and can be deleted. > Also drop some defines and a struct from that are unused > now together with the declarations of the four mentioned functions. > > Signed-off-by: Uwe Kleine-König > --- > Hello Michael, > > On Thu, Apr 13, 2023 at 10:11:25AM +1000, Michael Ellerman wrote: > > Uwe Kleine-König writes: > > > On Wed, Dec 28, 2022 at 03:51:29PM +0100, Uwe Kleine-König wrote: > > >> The four exported functions mpc52xx_lpbfifo_submit(), > > >> mpc52xx_lpbfifo_abort(), mpc52xx_lpbfifo_poll(), and > > >> mpc52xx_lpbfifo_start_xfer() are not used. So they can be dropped and the > > >> definitions needed to call them can be moved into the driver file. > > >> > > >> Signed-off-by: Uwe Kleine-König > > > > > > I never got feedback about this driver and it has not appeared in next > > > up to now. Did it fell through the cracks? > > > > Yeah. I was hoping someone would explain what's going on with the > > driver. > > > > Presumably there are some out-of-tree drivers that use the routines > > provided by this driver? > > I googled for the function names but the only related hits were > references to this thread :-) > > > I think rather than merging this patch, which keeps the code but makes > > it completely useless, do you mind sending a patch to remove the whole > > driver? Maybe that will get someone's attention. > > fair enough, here it is. What is your thought about this patch? If you (also) think getting it into next soon after a merge window closed, around now would be a good opportunity to do so .. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH 0/6] bus: fsl-mc: Make remove function return void
Li Yang writes: > On Mon, May 8, 2023 at 8:44 AM Uwe Kleine-König > wrote: >> >> Hello Leo, >> >> On Thu, Apr 13, 2023 at 08:00:04AM +0200, Uwe Kleine-König wrote: >> > On Wed, Apr 12, 2023 at 09:30:05PM +, Leo Li wrote: >> > > > On Fri, Mar 10, 2023 at 11:41:22PM +0100, Uwe Kleine-König wrote: >> > > > > Hello, >> > > > > >> > > > > many bus remove functions return an integer which is a historic >> > > > > misdesign that makes driver authors assume that there is some kind of >> > > > > error handling in the upper layers. This is wrong however and >> > > > > returning and error code only yields an error message. >> > > > > >> > > > > This series improves the fsl-mc bus by changing the remove callback >> > > > > to >> > > > > return no value instead. As a preparation all drivers are changed to >> > > > > return zero before so that they don't trigger the error message. >> > > > >> > > > Who is supposed to pick up this patch series (or point out a good >> > > > reason for >> > > > not taking it)? >> > > >> > > Previously Greg KH picked up MC bus patches. >> > > >> > > If no one is picking up them this time, I probably can take it through >> > > the fsl soc tree. >> > >> > I guess Greg won't pick up this series as he didn't get a copy of it :-) >> > >> > Browsing through the history of drivers/bus/fsl-mc there is no >> > consistent maintainer to see. So if you can take it, that's very >> > appreciated. >> >> My mail was meant encouraging, maybe it was too subtile? I'll try again: >> >> Yes, please apply, that would be wonderful! > > Sorry for missing your previous email. I will do that. Thanks. Does MAINTAINERS need updating? It says: QORIQ DPAA2 FSL-MC BUS DRIVER M: Stuart Yoder M: Laurentiu Tudor L: linux-ker...@vger.kernel.org S: Maintained ... F: drivers/bus/fsl-mc/ cheers
Re: [PATCH AUTOSEL 6.3 6/7] powerpc/fsl_uli1575: Allow to disable FSL_ULI1575 support
On Tuesday 09 May 2023 17:14:48 Michael Ellerman wrote:
> Randy Dunlap writes:
> > Hi--
> >
> > Just a heads up. This patch can cause build errors.
> > I sent a patch for these on 2023-APR-28:
> >
> > https://lore.kernel.org/linuxppc-dev/20230429043519.19807-1-rdun...@infradead.org/
> >
> > Michael, I think this is your area if I'm not mistaken.
>
> Yes. The fix is in my fixes branch as:
> 536d948a8dee ("powerpc/fsl_uli1575: fix kconfig warnings and build errors")
>
> But I don't think this commit (22fdf79171e8) really warrants going to
> stable, it's a nice-to-have but doesn't fix any pressing bugs.
Exactly. And also this patch alone without 1/8 would not work as in 1/8
https://lore.kernel.org/all/20230409000812.18904-2-p...@kernel.org/ was
added static inline variant of function which is used when ULI is
disabled.
> cheers
>
> > On 5/8/23 20:54, Sasha Levin wrote:
> >> From: Pali Rohár
> >>
> >> [ Upstream commit 22fdf79171e8509db54599fd2c05ef0022ee83f5 ]
> >>
> >> ULI1575 PCIe south bridge exists only on some Freescale boards. Allow to
> >> disable CONFIG_FSL_ULI1575 symbol when it is not explicitly selected and
> >> only implied. This is achieved by marking symbol as visible by providing
> >> short description. Also adds dependency for this symbol to prevent enabling
> >> it on platforms on which driver does not compile.
> >>
> >> Signed-off-by: Pali Rohár
> >> Signed-off-by: Michael Ellerman
> >> Link: https://msgid.link/20230409000812.18904-7-p...@kernel.org
> >> Signed-off-by: Sasha Levin
> >> ---
> >> arch/powerpc/platforms/Kconfig | 4 +++-
> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/powerpc/platforms/Kconfig
> >> b/arch/powerpc/platforms/Kconfig
> >> index d41dad227de84..608ac0290e3aa 100644
> >> --- a/arch/powerpc/platforms/Kconfig
> >> +++ b/arch/powerpc/platforms/Kconfig
> >> @@ -261,7 +261,9 @@ config CPM2
> >> on it (826x, 827x, 8560).
> >>
> >> config FSL_ULI1575
> >> - bool
> >> + bool "ULI1575 PCIe south bridge support"
> >> + depends on FSL_SOC_BOOKE || PPC_86xx
> >> + select FSL_PCI
> >>select GENERIC_ISA_DMA
> >>help
> >> Supports for the ULI1575 PCIe south bridge that exists on some
> >
> > --
> > ~Randy
Re: [PATCH AUTOSEL 6.3 6/7] powerpc/fsl_uli1575: Allow to disable FSL_ULI1575 support
Randy Dunlap writes:
> Hi--
>
> Just a heads up. This patch can cause build errors.
> I sent a patch for these on 2023-APR-28:
>
> https://lore.kernel.org/linuxppc-dev/20230429043519.19807-1-rdun...@infradead.org/
>
> Michael, I think this is your area if I'm not mistaken.
Yes. The fix is in my fixes branch as:
536d948a8dee ("powerpc/fsl_uli1575: fix kconfig warnings and build errors")
But I don't think this commit (22fdf79171e8) really warrants going to
stable, it's a nice-to-have but doesn't fix any pressing bugs.
cheers
> On 5/8/23 20:54, Sasha Levin wrote:
>> From: Pali Rohár
>>
>> [ Upstream commit 22fdf79171e8509db54599fd2c05ef0022ee83f5 ]
>>
>> ULI1575 PCIe south bridge exists only on some Freescale boards. Allow to
>> disable CONFIG_FSL_ULI1575 symbol when it is not explicitly selected and
>> only implied. This is achieved by marking symbol as visible by providing
>> short description. Also adds dependency for this symbol to prevent enabling
>> it on platforms on which driver does not compile.
>>
>> Signed-off-by: Pali Rohár
>> Signed-off-by: Michael Ellerman
>> Link: https://msgid.link/20230409000812.18904-7-p...@kernel.org
>> Signed-off-by: Sasha Levin
>> ---
>> arch/powerpc/platforms/Kconfig | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
>> index d41dad227de84..608ac0290e3aa 100644
>> --- a/arch/powerpc/platforms/Kconfig
>> +++ b/arch/powerpc/platforms/Kconfig
>> @@ -261,7 +261,9 @@ config CPM2
>>on it (826x, 827x, 8560).
>>
>> config FSL_ULI1575
>> -bool
>> +bool "ULI1575 PCIe south bridge support"
>> +depends on FSL_SOC_BOOKE || PPC_86xx
>> +select FSL_PCI
>> select GENERIC_ISA_DMA
>> help
>>Supports for the ULI1575 PCIe south bridge that exists on some
>
> --
> ~Randy
Re: linux-next: boot warning
Stephen Rothwell writes: > Hi all, > > Today's qemu test boot (powerpc pseries_le_defconfig) produced this > warning: > > [2.048588][T1] ipr: IBM Power RAID SCSI Device Driver version: 2.6.4 > (March 14, 2017) > [2.051560][T1] [ cut here ] > [2.052297][T1] WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:5925 > workqueue_sysfs_register+0x20/0x1f0 Caused by 59709bb84c22 scsi: Use alloc_ordered_workqueue() to create ordered workqueues. cheers > [2.053294][T1] Modules linked in: > [2.053678][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 6.4.0-rc1-01511-g91b79de175e1 #1 > [2.053899][T1] Hardware name: IBM pSeries (emulated by qemu) POWER8 > (raw) 0x4d0200 0xf04 of:SLOF,HEAD pSeries > [2.054099][T1] NIP: c0181d40 LR: c0182164 CTR: > c01b71e0 > [2.054171][T1] REGS: c47632c0 TRAP: 0700 Not tainted > (6.4.0-rc1-01511-g91b79de175e1) > [2.054279][T1] MSR: 82029033 CR: > 48000284 XER: > [2.054608][T1] CFAR: c0182160 IRQMASK: 0 > [2.054608][T1] GPR00: c0182164 c4763560 > c1558c00 c4d18600 > [2.054608][T1] GPR04: > c28eccd8 > [2.054608][T1] GPR08: 0008 > 48000288 > [2.054608][T1] GPR12: c2ad > c0013788 > [2.054608][T1] GPR16: > > [2.054608][T1] GPR20: > > [2.054608][T1] GPR24: c4d186b8 > c4d18610 c4d18620 > [2.054608][T1] GPR28: c299b310 > c4d18600 > [2.055488][T1] NIP [c0181d40] > workqueue_sysfs_register+0x20/0x1f0 > [2.055564][T1] LR [c0182164] alloc_workqueue+0x254/0x584 > [2.055858][T1] Call Trace: > [2.055989][T1] [c4763560] [c47635f0] > 0xc47635f0 (unreliable) > [2.056509][T1] [c47635f0] [c01823a8] > alloc_workqueue+0x498/0x584 > [2.056605][T1] [c47636a0] [c0ba016c] > scsi_host_alloc+0x2fc/0x500 > [2.056678][T1] [c4763730] [c0bdf7ec] > ibmvscsi_probe+0x6c/0xaf8 > [2.056746][T1] [c4763820] [c0105d4c] > vio_bus_probe+0x9c/0x4a0 > [2.056816][T1] [c47638e0] [c0b1c274] > really_probe+0x104/0x410 > [2.056885][T1] [c4763970] [c0b1c630] > __driver_probe_device+0xb0/0x1e0 > [2.056956][T1] [c47639f0] [c0b1c7b4] > driver_probe_device+0x54/0x130 > [2.057025][T1] [c4763a30] [c0b1cac8] > __driver_attach+0xd8/0x200 > [2.057092][T1] [c4763a70] [c0b18cd4] > bus_for_each_dev+0xb4/0x140 > [2.057158][T1] [c4763ad0] [c0b1b824] > driver_attach+0x34/0x50 > [2.057226][T1] [c4763af0] [c0b1ac1c] > bus_add_driver+0x13c/0x2d0 > [2.057292][T1] [c4763b80] [c0b1e3c4] > driver_register+0xa4/0x1b0 > [2.057360][T1] [c4763bf0] [c0108054] > __vio_register_driver+0x74/0x9c > [2.057428][T1] [c4763c10] [c2063690] > ibmvscsi_module_init+0x98/0xd4 > [2.057500][T1] [c4763c40] [c00131a0] > do_one_initcall+0x80/0x320 > [2.057583][T1] [c4763d20] [c20049b4] > kernel_init_freeable+0x304/0x3ac > [2.057657][T1] [c4763df0] [c00137b0] > kernel_init+0x30/0x1a0 > [2.057723][T1] [c4763e50] [c000debc] > ret_from_kernel_user_thread+0x14/0x1c > [2.057807][T1] --- interrupt: 0 at 0x0 > [2.057858][T1] NIP: LR: CTR: > > [2.057909][T1] REGS: c4763e80 TRAP: Not tainted > (6.4.0-rc1-01511-g91b79de175e1) > [2.057964][T1] MSR: <> CR: XER: > [2.058031][T1] CFAR: IRQMASK: 0 > [2.058031][T1] GPR00: > > [2.058031][T1] GPR04: > > [2.058031][T1] GPR08: > > [2.058031][T1] GPR12: > > [2.058031][T1] GPR16: > > [2.058031][T1] GPR20: > > [2.058031][T1] GPR24:
[RFC PATCH] asm-generic: Unify uapi bitsperlong.h
Now we specify the minimal version of GCC as 5.1 and Clang/LLVM as 11.0.0 in Documentation/process/changes.rst, __CHAR_BIT__ and __SIZEOF_LONG__ are usable, just define __BITS_PER_LONG as (__CHAR_BIT__ * __SIZEOF_LONG__) in asm-generic uapi bitsperlong.h, simpler, works everywhere. Remove all the arch specific uapi bitsperlong.h which will be generated as arch/*/include/generated/uapi/asm/bitsperlong.h. Suggested-by: Xi Ruoyao Link: https://lore.kernel.org/all/d3e255e4746de44c9903c4433616d44ffcf18d1b.ca...@xry111.site/ Signed-off-by: Tiezhu Yang --- This is based on 6.4-rc1 arch/alpha/include/uapi/asm/bitsperlong.h | 9 arch/arm64/include/uapi/asm/bitsperlong.h | 24 --- arch/ia64/include/uapi/asm/bitsperlong.h | 9 arch/loongarch/include/uapi/asm/bitsperlong.h | 9 arch/mips/include/uapi/asm/bitsperlong.h | 9 arch/parisc/include/uapi/asm/bitsperlong.h | 13 --- arch/powerpc/include/uapi/asm/bitsperlong.h| 13 --- arch/riscv/include/uapi/asm/bitsperlong.h | 14 --- arch/s390/include/uapi/asm/bitsperlong.h | 14 --- arch/sparc/include/uapi/asm/bitsperlong.h | 14 --- arch/x86/include/uapi/asm/bitsperlong.h| 14 --- include/uapi/asm-generic/bitsperlong.h | 11 + tools/arch/alpha/include/uapi/asm/bitsperlong.h| 9 tools/arch/arm64/include/uapi/asm/bitsperlong.h| 24 --- tools/arch/hexagon/include/uapi/asm/bitsperlong.h | 27 -- tools/arch/ia64/include/uapi/asm/bitsperlong.h | 9 .../arch/loongarch/include/uapi/asm/bitsperlong.h | 9 .../arch/microblaze/include/uapi/asm/bitsperlong.h | 2 -- tools/arch/mips/include/uapi/asm/bitsperlong.h | 9 tools/arch/parisc/include/uapi/asm/bitsperlong.h | 15 tools/arch/powerpc/include/uapi/asm/bitsperlong.h | 13 --- tools/arch/riscv/include/uapi/asm/bitsperlong.h| 14 --- tools/arch/s390/include/uapi/asm/bitsperlong.h | 13 --- tools/arch/sparc/include/uapi/asm/bitsperlong.h| 13 --- tools/arch/x86/include/uapi/asm/bitsperlong.h | 13 --- tools/include/uapi/asm-generic/bitsperlong.h | 12 ++ tools/include/uapi/asm/bitsperlong.h | 24 --- 27 files changed, 3 insertions(+), 356 deletions(-) delete mode 100644 arch/alpha/include/uapi/asm/bitsperlong.h delete mode 100644 arch/arm64/include/uapi/asm/bitsperlong.h delete mode 100644 arch/ia64/include/uapi/asm/bitsperlong.h delete mode 100644 arch/loongarch/include/uapi/asm/bitsperlong.h delete mode 100644 arch/mips/include/uapi/asm/bitsperlong.h delete mode 100644 arch/parisc/include/uapi/asm/bitsperlong.h delete mode 100644 arch/powerpc/include/uapi/asm/bitsperlong.h delete mode 100644 arch/riscv/include/uapi/asm/bitsperlong.h delete mode 100644 arch/s390/include/uapi/asm/bitsperlong.h delete mode 100644 arch/sparc/include/uapi/asm/bitsperlong.h delete mode 100644 arch/x86/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/alpha/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/arm64/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/hexagon/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/ia64/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/loongarch/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/microblaze/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/mips/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/parisc/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/powerpc/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/riscv/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/s390/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/sparc/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/x86/include/uapi/asm/bitsperlong.h delete mode 100644 tools/include/uapi/asm/bitsperlong.h diff --git a/arch/alpha/include/uapi/asm/bitsperlong.h b/arch/alpha/include/uapi/asm/bitsperlong.h deleted file mode 100644 index 6c5bf7d..000 --- a/arch/alpha/include/uapi/asm/bitsperlong.h +++ /dev/null @@ -1,9 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -#ifndef __ASM_ALPHA_BITSPERLONG_H -#define __ASM_ALPHA_BITSPERLONG_H - -#define __BITS_PER_LONG 64 - -#include - -#endif /* __ASM_ALPHA_BITSPERLONG_H */ diff --git a/arch/arm64/include/uapi/asm/bitsperlong.h b/arch/arm64/include/uapi/asm/bitsperlong.h deleted file mode 100644 index 485d60be..000 --- a/arch/arm64/include/uapi/asm/bitsperlong.h +++ /dev/null @@ -1,24 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -/* - * Copyright (C) 2012 ARM Ltd. - * - * This program is free software; you can redistribute it and/or modify - * it
Re: [PATCH v5 00/26] Remove COMMAND_LINE_SIZE from uapi
Hi Arnd,
On Mon, Mar 6, 2023 at 11:05 AM Alexandre Ghiti wrote:
>
> This all came up in the context of increasing COMMAND_LINE_SIZE in the
> RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> maximum length of /proc/cmdline and userspace could staticly rely on
> that to be correct.
>
> Usually I wouldn't mess around with changing this sort of thing, but
> PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
> increasing, but they're from before the UAPI split so I'm not quite sure
> what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> asm-generic/setup.h.").
>
> It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> part of the uapi to begin with, and userspace should be able to handle
> /proc/cmdline of whatever length it turns out to be. I don't see any
> references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> search, but that's not really enough to consider it unused on my end.
>
> This issue was already considered in s390 and they reached the same
> conclusion in commit 622021cd6c56 ("s390: make command line
> configurable").
>
> The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> shouldn't be part of uapi, so this now touches all the ports. I've
> tried to split this all out and leave it bisectable, but I haven't
> tested it all that aggressively.
>
> Changes since v4
>
Re: [PATCH 03/12] powerpc: qspinlock: Enforce qnode writes prior to publishing to queue
On Tue May 9, 2023 at 3:26 PM AEST, Rohan McLure wrote: > > On 9 May 2023, at 12:04 pm, Nicholas Piggin wrote: > > > > On Mon May 8, 2023 at 12:01 PM AEST, Rohan McLure wrote: > >> Use a compiler barrier to enforce that all fields of a new struct qnode > >> be written to (especially the lock value) before publishing the qnode to > >> the waitqueue. > > > > publish_tail_cpu is the release barrier for this and includes the memory > > clobber there. Can we annotate that instead? > > Got it, I see that one now. > > On another note though, it looks like the memory clobber doesn’t serve > to squash KCSAN warnings here. Aha, publish_tail_cpu() needs a kcsan_release(). Thanks, Nick
Re: [PATCH] ASoC: fsl_sai: MCLK bind with TX/RX enable bit
On Fri, 05 May 2023 15:55:22 +0800, Shengjiu Wang wrote: > On i.MX8MP, the sai MCLK is bound with TX/RX enable bit, > which means the TX/RE enable bit need to be enabled then > MCLK can be output on PAD. > > Some codec (for example: WM8962) needs the MCLK output > earlier, otherwise there will be issue for codec > configuration. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_sai: MCLK bind with TX/RX enable bit commit: 3e4a826129980fed0e3e746a7822f2f204dfc24a All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
