* [PATCH] powerpc/powernv/dump: Fix race while processing OPAL dump
From: Vasant Hegde @ 2020-10-07 10:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Vasant Hegde, Mahesh Salgaonkar
Every dump reported by OPAL is exported to userspace through a sysfs
interface and notified using kobject_uevent(). The userspace daemon
(opal_errd) then reads the dump and acknowledges that the dump is
saved safely to disk. Once acknowledged the kernel removes the
respective sysfs file entry causing respective resources to be
released including kobject.
However it's possible the userspace daemon may already be scanning
dump entries when a new sysfs dump entry is created by the kernel.
User daemon may read this new entry and ack it even before kernel can
notify userspace about it through kobject_uevent() call. If that
happens then we have a potential race between
dump_ack_store->kobject_put() and kobject_uevent which can lead to
use-after-free of a kernfs object resulting in a kernel crash.
This patch fixes this race by protecting the sysfs file
creation/notification by holding a reference count on kobject until we
safely send kobject_uevent().
The function create_dump_obj() returns the dump object which if used
by caller function will end up in use-after-free problem again.
However, the return value of create_dump_obj() function isn't being
used today and there is no need as well. Hence change it to return
void to make this fix complete.
Fixes: c7e64b9c ("powerpc/powernv Platform dump interface")
CC: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/opal-dump.c | 31 +++++++++++++++++-----
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-dump.c b/arch/powerpc/platforms/powernv/opal-dump.c
index 543c816fa99e..7e6eeedec32b 100644
--- a/arch/powerpc/platforms/powernv/opal-dump.c
+++ b/arch/powerpc/platforms/powernv/opal-dump.c
@@ -318,15 +318,14 @@ static ssize_t dump_attr_read(struct file *filep, struct kobject *kobj,
return count;
}
-static struct dump_obj *create_dump_obj(uint32_t id, size_t size,
- uint32_t type)
+static void create_dump_obj(uint32_t id, size_t size, uint32_t type)
{
struct dump_obj *dump;
int rc;
dump = kzalloc(sizeof(*dump), GFP_KERNEL);
if (!dump)
- return NULL;
+ return;
dump->kobj.kset = dump_kset;
@@ -346,21 +345,39 @@ static struct dump_obj *create_dump_obj(uint32_t id, size_t size,
rc = kobject_add(&dump->kobj, NULL, "0x%x-0x%x", type, id);
if (rc) {
kobject_put(&dump->kobj);
- return NULL;
+ return;
}
+ /*
+ * As soon as the sysfs file for this dump is created/activated there is
+ * a chance the opal_errd daemon (or any userspace) might read and
+ * acknowledge the dump before kobject_uevent() is called. If that
+ * happens then there is a potential race between
+ * dump_ack_store->kobject_put() and kobject_uevent() which leads to a
+ * use-after-free of a kernfs object resulting in a kernel crash.
+ *
+ * To avoid that, we need to take a reference on behalf of the bin file,
+ * so that our reference remains valid while we call kobject_uevent().
+ * We then drop our reference before exiting the function, leaving the
+ * bin file to drop the last reference (if it hasn't already).
+ */
+
+ /* Take a reference for the bin file */
+ kobject_get(&dump->kobj);
rc = sysfs_create_bin_file(&dump->kobj, &dump->dump_attr);
if (rc) {
kobject_put(&dump->kobj);
- return NULL;
+ /* Drop reference count taken for bin file */
+ kobject_put(&dump->kobj);
+ return;
}
pr_info("%s: New platform dump. ID = 0x%x Size %u\n",
__func__, dump->id, dump->size);
kobject_uevent(&dump->kobj, KOBJ_ADD);
-
- return dump;
+ /* Drop reference count taken for bin file */
+ kobject_put(&dump->kobj);
}
static irqreturn_t process_dump(int irq, void *data)
--
2.26.2
^ permalink raw reply related
* [PATCH] powerpc/security: Fix link stack flush instruction
From: Nicholas Piggin @ 2020-10-07 8:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
The inline execution path for the hardware assisted branch flush
instruction failed to set CTR to the correct value before bcctr,
causing a crash when the feature is enabled.
Fixes: 4d24e21cc694 ("powerpc/security: Allow for processors that flush the link stack using the special bcctr")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/asm-prototypes.h | 4 ++-
arch/powerpc/kernel/entry_64.S | 8 ++++--
arch/powerpc/kernel/security.c | 34 ++++++++++++++++-------
3 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/asm-prototypes.h b/arch/powerpc/include/asm/asm-prototypes.h
index de14b1a34d56..9652756b0694 100644
--- a/arch/powerpc/include/asm/asm-prototypes.h
+++ b/arch/powerpc/include/asm/asm-prototypes.h
@@ -144,7 +144,9 @@ void _kvmppc_restore_tm_pr(struct kvm_vcpu *vcpu, u64 guest_msr);
void _kvmppc_save_tm_pr(struct kvm_vcpu *vcpu, u64 guest_msr);
/* Patch sites */
-extern s32 patch__call_flush_branch_caches;
+extern s32 patch__call_flush_branch_caches1;
+extern s32 patch__call_flush_branch_caches2;
+extern s32 patch__call_flush_branch_caches3;
extern s32 patch__flush_count_cache_return;
extern s32 patch__flush_link_stack_return;
extern s32 patch__call_kvm_flush_link_stack;
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 733e40eba4eb..2f3846192ec7 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -430,7 +430,11 @@ _ASM_NOKPROBE_SYMBOL(save_nvgprs);
#define FLUSH_COUNT_CACHE \
1: nop; \
- patch_site 1b, patch__call_flush_branch_caches
+ patch_site 1b, patch__call_flush_branch_caches1; \
+1: nop; \
+ patch_site 1b, patch__call_flush_branch_caches2; \
+1: nop; \
+ patch_site 1b, patch__call_flush_branch_caches3
.macro nops number
.rept \number
@@ -512,7 +516,7 @@ _GLOBAL(_switch)
kuap_check_amr r9, r10
- FLUSH_COUNT_CACHE
+ FLUSH_COUNT_CACHE /* Clobbers r9, ctr */
/*
* On SMP kernels, care must be taken because a task may be
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index c9876aab3142..e4e1a94ccf6a 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -430,30 +430,44 @@ device_initcall(stf_barrier_debugfs_init);
static void update_branch_cache_flush(void)
{
+ u32 *site;
+
#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
+ site = &patch__call_kvm_flush_link_stack;
// This controls the branch from guest_exit_cont to kvm_flush_link_stack
if (link_stack_flush_type == BRANCH_CACHE_FLUSH_NONE) {
- patch_instruction_site(&patch__call_kvm_flush_link_stack,
- ppc_inst(PPC_INST_NOP));
+ patch_instruction_site(site, ppc_inst(PPC_INST_NOP));
} else {
// Could use HW flush, but that could also flush count cache
- patch_branch_site(&patch__call_kvm_flush_link_stack,
- (u64)&kvm_flush_link_stack, BRANCH_SET_LINK);
+ patch_branch_site(site, (u64)&kvm_flush_link_stack, BRANCH_SET_LINK);
}
#endif
+ // Patch out the bcctr first, then nop the rest
+ site = &patch__call_flush_branch_caches3;
+ patch_instruction_site(site, ppc_inst(PPC_INST_NOP));
+ site = &patch__call_flush_branch_caches2;
+ patch_instruction_site(site, ppc_inst(PPC_INST_NOP));
+ site = &patch__call_flush_branch_caches1;
+ patch_instruction_site(site, ppc_inst(PPC_INST_NOP));
+
// This controls the branch from _switch to flush_branch_caches
if (count_cache_flush_type == BRANCH_CACHE_FLUSH_NONE &&
link_stack_flush_type == BRANCH_CACHE_FLUSH_NONE) {
- patch_instruction_site(&patch__call_flush_branch_caches,
- ppc_inst(PPC_INST_NOP));
+ // Nothing to be done
+
} else if (count_cache_flush_type == BRANCH_CACHE_FLUSH_HW &&
link_stack_flush_type == BRANCH_CACHE_FLUSH_HW) {
- patch_instruction_site(&patch__call_flush_branch_caches,
- ppc_inst(PPC_INST_BCCTR_FLUSH));
+ // Patch in the bcctr last
+ site = &patch__call_flush_branch_caches1;
+ patch_instruction_site(site, ppc_inst(0x39207fff)); // li r9,0x7fff
+ site = &patch__call_flush_branch_caches2;
+ patch_instruction_site(site, ppc_inst(0x7d2903a6)); // mtctr r9
+ site = &patch__call_flush_branch_caches3;
+ patch_instruction_site(site, ppc_inst(PPC_INST_BCCTR_FLUSH));
+
} else {
- patch_branch_site(&patch__call_flush_branch_caches,
- (u64)&flush_branch_caches, BRANCH_SET_LINK);
+ patch_branch_site(site, (u64)&flush_branch_caches, BRANCH_SET_LINK);
// If we just need to flush the link stack, early return
if (count_cache_flush_type == BRANCH_CACHE_FLUSH_NONE) {
--
2.23.0
^ permalink raw reply related
* [PATCH 2/2] sparc: Check VMA range in sparc_validate_prot()
From: Jann Horn @ 2020-10-07 7:39 UTC (permalink / raw)
To: David S. Miller, sparclinux, Andrew Morton, linux-mm
Cc: Catalin Marinas, linuxppc-dev, linux-kernel, Christoph Hellwig,
Khalid Aziz, Paul Mackerras, Anthony Yznaga, Will Deacon,
linux-arm-kernel
In-Reply-To: <20201007073932.865218-1-jannh@google.com>
sparc_validate_prot() is called from do_mprotect_pkey() as
arch_validate_prot(); it tries to ensure that an mprotect() call can't
enable ADI on incompatible VMAs.
The current implementation only checks that the VMA at the start address
matches the rules for ADI mappings; instead, check all VMAs that will be
affected by mprotect().
(This hook is called before mprotect() makes sure that the specified range
is actually covered by VMAs, and mprotect() returns specific error codes
when that's not the case. In order for mprotect() to still generate the
same error codes for mprotect(<unmapped_ptr>, <len>, ...|PROT_ADI), we need
to *accept* cases where the range is not fully covered by VMAs.)
Cc: stable@vger.kernel.org
Fixes: 74a04967482f ("sparc64: Add support for ADI (Application Data Integrity)")
Signed-off-by: Jann Horn <jannh@google.com>
---
compile-tested only, I don't have a Sparc ADI setup - might be nice if some
Sparc person could test this?
arch/sparc/include/asm/mman.h | 50 +++++++++++++++++++++--------------
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/arch/sparc/include/asm/mman.h b/arch/sparc/include/asm/mman.h
index e85222c76585..6dced75567c3 100644
--- a/arch/sparc/include/asm/mman.h
+++ b/arch/sparc/include/asm/mman.h
@@ -60,31 +60,41 @@ static inline int sparc_validate_prot(unsigned long prot, unsigned long addr,
if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_ADI))
return 0;
if (prot & PROT_ADI) {
+ struct vm_area_struct *vma, *next;
+
if (!adi_capable())
return 0;
- if (addr) {
- struct vm_area_struct *vma;
+ vma = find_vma(current->mm, addr);
+ /* if @addr is unmapped, let mprotect() deal with it */
+ if (!vma || vma->vm_start > addr)
+ return 1;
+ while (1) {
+ /* ADI can not be enabled on PFN
+ * mapped pages
+ */
+ if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
+ return 0;
- vma = find_vma(current->mm, addr);
- if (vma) {
- /* ADI can not be enabled on PFN
- * mapped pages
- */
- if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
- return 0;
+ /* Mergeable pages can become unmergeable
+ * if ADI is enabled on them even if they
+ * have identical data on them. This can be
+ * because ADI enabled pages with identical
+ * data may still not have identical ADI
+ * tags on them. Disallow ADI on mergeable
+ * pages.
+ */
+ if (vma->vm_flags & VM_MERGEABLE)
+ return 0;
- /* Mergeable pages can become unmergeable
- * if ADI is enabled on them even if they
- * have identical data on them. This can be
- * because ADI enabled pages with identical
- * data may still not have identical ADI
- * tags on them. Disallow ADI on mergeable
- * pages.
- */
- if (vma->vm_flags & VM_MERGEABLE)
- return 0;
- }
+ /* reached the end of the range without errors? */
+ if (addr+len <= vma->vm_end)
+ return 1;
+ next = vma->vm_next;
+ /* if a VMA hole follows, let mprotect() deal with it */
+ if (!next || next->vm_start != vma->vm_end)
+ return 1;
+ vma = next;
}
}
return 1;
--
2.28.0.806.g8561365e88-goog
^ permalink raw reply related
* [PATCH 1/2] mm/mprotect: Call arch_validate_prot under mmap_lock and with length
From: Jann Horn @ 2020-10-07 7:39 UTC (permalink / raw)
To: David S. Miller, sparclinux, Andrew Morton, linux-mm
Cc: Catalin Marinas, linuxppc-dev, linux-kernel, Christoph Hellwig,
Khalid Aziz, Paul Mackerras, Anthony Yznaga, Will Deacon,
linux-arm-kernel
arch_validate_prot() is a hook that can validate whether a given set of
protection flags is valid in an mprotect() operation. It is given the set
of protection flags and the address being modified.
However, the address being modified can currently not actually be used in
a meaningful way because:
1. Only the address is given, but not the length, and the operation can
span multiple VMAs. Therefore, the callee can't actually tell which
virtual address range, or which VMAs, are being targeted.
2. The mmap_lock is not held, meaning that if the callee were to check
the VMA at @addr, that VMA would be unrelated to the one the
operation is performed on.
Currently, custom arch_validate_prot() handlers are defined by
arm64, powerpc and sparc.
arm64 and powerpc don't care about the address range, they just check the
flags against CPU support masks.
sparc's arch_validate_prot() attempts to look at the VMA, but doesn't take
the mmap_lock.
Change the function signature to also take a length, and move the
arch_validate_prot() call in mm/mprotect.c down into the locked region.
Cc: stable@vger.kernel.org
Fixes: 9035cf9a97e4 ("mm: Add address parameter to arch_validate_prot()")
Suggested-by: Khalid Aziz <khalid.aziz@oracle.com>
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Jann Horn <jannh@google.com>
---
arch/arm64/include/asm/mman.h | 4 ++--
arch/powerpc/include/asm/mman.h | 3 ++-
arch/powerpc/kernel/syscalls.c | 2 +-
arch/sparc/include/asm/mman.h | 6 ++++--
include/linux/mman.h | 3 ++-
mm/mprotect.c | 6 ++++--
6 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/mman.h b/arch/arm64/include/asm/mman.h
index 081ec8de9ea6..0876a87986dc 100644
--- a/arch/arm64/include/asm/mman.h
+++ b/arch/arm64/include/asm/mman.h
@@ -23,7 +23,7 @@ static inline pgprot_t arch_vm_get_page_prot(unsigned long vm_flags)
#define arch_vm_get_page_prot(vm_flags) arch_vm_get_page_prot(vm_flags)
static inline bool arch_validate_prot(unsigned long prot,
- unsigned long addr __always_unused)
+ unsigned long addr __always_unused, unsigned long len __always_unused)
{
unsigned long supported = PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM;
@@ -32,6 +32,6 @@ static inline bool arch_validate_prot(unsigned long prot,
return (prot & ~supported) == 0;
}
-#define arch_validate_prot(prot, addr) arch_validate_prot(prot, addr)
+#define arch_validate_prot(prot, addr, len) arch_validate_prot(prot, addr, len)
#endif /* ! __ASM_MMAN_H__ */
diff --git a/arch/powerpc/include/asm/mman.h b/arch/powerpc/include/asm/mman.h
index 7cb6d18f5cd6..65dd9b594985 100644
--- a/arch/powerpc/include/asm/mman.h
+++ b/arch/powerpc/include/asm/mman.h
@@ -36,7 +36,8 @@ static inline pgprot_t arch_vm_get_page_prot(unsigned long vm_flags)
}
#define arch_vm_get_page_prot(vm_flags) arch_vm_get_page_prot(vm_flags)
-static inline bool arch_validate_prot(unsigned long prot, unsigned long addr)
+static inline bool arch_validate_prot(unsigned long prot, unsigned long addr,
+ unsigned long len)
{
if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_SAO))
return false;
diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index 078608ec2e92..b1fabb97d138 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -43,7 +43,7 @@ static inline long do_mmap2(unsigned long addr, size_t len,
{
long ret = -EINVAL;
- if (!arch_validate_prot(prot, addr))
+ if (!arch_validate_prot(prot, addr, len))
goto out;
if (shift) {
diff --git a/arch/sparc/include/asm/mman.h b/arch/sparc/include/asm/mman.h
index f94532f25db1..e85222c76585 100644
--- a/arch/sparc/include/asm/mman.h
+++ b/arch/sparc/include/asm/mman.h
@@ -52,9 +52,11 @@ static inline pgprot_t sparc_vm_get_page_prot(unsigned long vm_flags)
return (vm_flags & VM_SPARC_ADI) ? __pgprot(_PAGE_MCD_4V) : __pgprot(0);
}
-#define arch_validate_prot(prot, addr) sparc_validate_prot(prot, addr)
-static inline int sparc_validate_prot(unsigned long prot, unsigned long addr)
+#define arch_validate_prot(prot, addr, len) sparc_validate_prot(prot, addr, len)
+static inline int sparc_validate_prot(unsigned long prot, unsigned long addr,
+ unsigned long len)
{
+ mmap_assert_write_locked(current->mm);
if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_ADI))
return 0;
if (prot & PROT_ADI) {
diff --git a/include/linux/mman.h b/include/linux/mman.h
index 6f34c33075f9..5b4d554d3189 100644
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -96,7 +96,8 @@ static inline void vm_unacct_memory(long pages)
*
* Returns true if the prot flags are valid
*/
-static inline bool arch_validate_prot(unsigned long prot, unsigned long addr)
+static inline bool arch_validate_prot(unsigned long prot, unsigned long addr,
+ unsigned long len)
{
return (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM)) == 0;
}
diff --git a/mm/mprotect.c b/mm/mprotect.c
index ce8b8a5eacbb..e2d6b51acbf8 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -533,14 +533,16 @@ static int do_mprotect_pkey(unsigned long start, size_t len,
end = start + len;
if (end <= start)
return -ENOMEM;
- if (!arch_validate_prot(prot, start))
- return -EINVAL;
reqprot = prot;
if (mmap_write_lock_killable(current->mm))
return -EINTR;
+ error = -EINVAL;
+ if (!arch_validate_prot(prot, start, len))
+ goto out;
+
/*
* If userspace did not allocate the pkey, do not let
* them use it here.
base-commit: c85fb28b6f999db9928b841f63f1beeb3074eeca
--
2.28.0.806.g8561365e88-goog
^ permalink raw reply related
* Re: [PATCH] crypto: talitos - Fix sparse warnings
From: Herbert Xu @ 2020-10-07 6:50 UTC (permalink / raw)
To: Christophe Leroy
Cc: linuxppc-dev, Kim Phillips, Linux Crypto Mailing List,
Horia Geantă
In-Reply-To: <20201003191553.Horde.qhVjpQA-iJND7COibFfWZQ7@messagerie.c-s.fr>
On Sat, Oct 03, 2020 at 07:15:53PM +0200, Christophe Leroy wrote:
>
> The following changes fix the sparse warnings with less churn:
Yes that works too. Can you please submit this patch?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [powerpc:next-test 76/183] arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'
From: Christophe Leroy @ 2020-10-07 6:03 UTC (permalink / raw)
To: kernel test robot, Michael Ellerman
Cc: clang-built-linux, kbuild-all, linuxppc-dev
In-Reply-To: <202010070441.K8Bb46Rt-lkp@intel.com>
Le 06/10/2020 à 22:41, kernel test robot a écrit :
> Hi Michael,
>
> First bad commit (maybe != root cause):
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
> head: 72cdd117c449896c707fc6cfe5b90978160697d0
> commit: 231b232df8f67e7d37af01259c21f2a131c3911e [76/183] powerpc/64: Make VDSO32 track COMPAT on 64-bit
> config: powerpc-randconfig-r033-20201005 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 1127662c6dc2a276839c75a42238b11a3ad00f32)
There has been already a discussion on this, see
https://groups.google.com/g/clang-built-linux/c/ayNmi3HoNdY/m/ROdg7avVBwAJ
This apparently is a clang issue. The commit mentionned here is only exposing the issue, but the
issue is not in the commit itself.
Regardless, this error should go away when we switch to the generic C VDSO.
Christophe
^ permalink raw reply
* Re: [PATCH v2 3/4] powerpc/memhotplug: Make lmb size 64bit
From: Michael Ellerman @ 2020-10-07 5:56 UTC (permalink / raw)
To: Nathan Lynch, Aneesh Kumar K.V; +Cc: linuxppc-dev, stable
In-Reply-To: <87pn7lxe5k.fsf@linux.ibm.com>
Nathan Lynch <nathanl@linux.ibm.com> writes:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
>> @@ -322,12 +322,16 @@ static int pseries_remove_mem_node(struct device_node *np)
>> /*
>> * Find the base address and size of the memblock
>> */
>> - regs = of_get_property(np, "reg", NULL);
>> - if (!regs)
>> + prop = of_get_property(np, "reg", NULL);
>> + if (!prop)
>> return ret;
>>
>> - base = be64_to_cpu(*(unsigned long *)regs);
>> - lmb_size = be32_to_cpu(regs[3]);
>> + /*
>> + * "reg" property represents (addr,size) tuple.
>> + */
>> + base = of_read_number(prop, mem_addr_cells);
>> + prop += mem_addr_cells;
>> + lmb_size = of_read_number(prop, mem_size_cells);
>
> Would of_n_size_cells() and of_n_addr_cells() work here?
Yes that should work and be cleaner.
cheers
^ permalink raw reply
* [PATCH v2] powerpc/mm: Update tlbiel loop on POWER10
From: Aneesh Kumar K.V @ 2020-10-07 5:33 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: Aneesh Kumar K.V, npiggin
With POWER10, single tlbiel instruction invalidates all the congruence
class of the TLB and hence we need to issue only one tlbiel with SET=0.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/kvm/book3s_hv.c | 7 ++++++-
arch/powerpc/kvm/book3s_hv_builtin.c | 11 ++++++++++-
arch/powerpc/mm/book3s64/radix_tlb.c | 23 ++++++++++++++++-------
3 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 3bd3118c7633..00b5c5981db5 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4939,7 +4939,12 @@ static int kvmppc_core_init_vm_hv(struct kvm *kvm)
* Work out how many sets the TLB has, for the use of
* the TLB invalidation loop in book3s_hv_rmhandlers.S.
*/
- if (radix_enabled())
+ if (cpu_has_feature(CPU_FTR_ARCH_31)) {
+ /*
+ * P10 will flush all the congruence class with a single tlbiel
+ */
+ kvm->arch.tlb_sets = 1;
+ } else if (radix_enabled())
kvm->arch.tlb_sets = POWER9_TLB_SETS_RADIX; /* 128 */
else if (cpu_has_feature(CPU_FTR_ARCH_300))
kvm->arch.tlb_sets = POWER9_TLB_SETS_HASH; /* 256 */
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c b/arch/powerpc/kvm/book3s_hv_builtin.c
index 073617ce83e0..2803a4b01109 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -702,6 +702,7 @@ static void wait_for_sync(struct kvm_split_mode *sip, int phase)
void kvmhv_p9_set_lpcr(struct kvm_split_mode *sip)
{
+ int num_sets;
unsigned long rb, set;
/* wait for every other thread to get to real mode */
@@ -712,11 +713,19 @@ void kvmhv_p9_set_lpcr(struct kvm_split_mode *sip)
mtspr(SPRN_LPID, sip->lpidr_req);
isync();
+ /*
+ * P10 will flush all the congruence class with a single tlbiel
+ */
+ if (cpu_has_feature(CPU_FTR_ARCH_31))
+ num_sets = 1;
+ else
+ num_sets = POWER9_TLB_SETS_RADIX;
+
/* Invalidate the TLB on thread 0 */
if (local_paca->kvm_hstate.tid == 0) {
sip->do_set = 0;
asm volatile("ptesync" : : : "memory");
- for (set = 0; set < POWER9_TLB_SETS_RADIX; ++set) {
+ for (set = 0; set < num_sets; ++set) {
rb = TLBIEL_INVAL_SET_LPID +
(set << TLBIEL_INVAL_SET_SHIFT);
asm volatile(PPC_TLBIEL(%0, %1, 0, 0, 0) : :
diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c b/arch/powerpc/mm/book3s64/radix_tlb.c
index 143b4fd396f0..9e76ba766b3c 100644
--- a/arch/powerpc/mm/book3s64/radix_tlb.c
+++ b/arch/powerpc/mm/book3s64/radix_tlb.c
@@ -56,14 +56,21 @@ static void tlbiel_all_isa300(unsigned int num_sets, unsigned int is)
if (early_cpu_has_feature(CPU_FTR_HVMODE)) {
/* MSR[HV] should flush partition scope translations first. */
tlbiel_radix_set_isa300(0, is, 0, RIC_FLUSH_ALL, 0);
- for (set = 1; set < num_sets; set++)
- tlbiel_radix_set_isa300(set, is, 0, RIC_FLUSH_TLB, 0);
+
+ if (!early_cpu_has_feature(CPU_FTR_ARCH_31)) {
+ for (set = 1; set < num_sets; set++)
+ tlbiel_radix_set_isa300(set, is, 0,
+ RIC_FLUSH_TLB, 0);
+ }
}
/* Flush process scoped entries. */
tlbiel_radix_set_isa300(0, is, 0, RIC_FLUSH_ALL, 1);
- for (set = 1; set < num_sets; set++)
- tlbiel_radix_set_isa300(set, is, 0, RIC_FLUSH_TLB, 1);
+
+ if (!early_cpu_has_feature(CPU_FTR_ARCH_31)) {
+ for (set = 1; set < num_sets; set++)
+ tlbiel_radix_set_isa300(set, is, 0, RIC_FLUSH_TLB, 1);
+ }
asm volatile("ptesync": : :"memory");
}
@@ -300,9 +307,11 @@ static __always_inline void _tlbiel_pid(unsigned long pid, unsigned long ric)
return;
}
- /* For the remaining sets, just flush the TLB */
- for (set = 1; set < POWER9_TLB_SETS_RADIX ; set++)
- __tlbiel_pid(pid, set, RIC_FLUSH_TLB);
+ if (!cpu_has_feature(CPU_FTR_ARCH_31)) {
+ /* For the remaining sets, just flush the TLB */
+ for (set = 1; set < POWER9_TLB_SETS_RADIX ; set++)
+ __tlbiel_pid(pid, set, RIC_FLUSH_TLB);
+ }
asm volatile("ptesync": : :"memory");
asm volatile(PPC_RADIX_INVALIDATE_ERAT_USER "; isync" : : :"memory");
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v2 1/2] powerpc/rtas: Restrict RTAS requests from userspace
From: Andrew Donnellan @ 2020-10-07 5:10 UTC (permalink / raw)
To: Sasha Levin, linuxppc-dev; +Cc: nathanl, leobras.c, stable, dja
In-Reply-To: <20200826135348.AD06422B4B@mail.kernel.org>
On 26/8/20 11:53 pm, Sasha Levin wrote:
> How should we proceed with this patch?
mpe: I believe we came to the conclusion that we shouldn't put this in
stable just yet?
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* [PATCH 2/2] powerpc/pseries/eeh: Fix use of uninitialised variable
From: Oliver O'Halloran @ 2020-10-07 4:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20201007040903.819081-1-oohall@gmail.com>
If the RTAS call to query the PE address for a device fails we jump the
err: label where an error message is printed along with the return code.
However, the printed return code is from the "ret" variable which isn't set
at that point since we assigned the result to "addr" instead. Fix this by
consistently using the "ret" variable for the result of the RTAS call
helpers an dropping the "addr" local variable"
Fixes: 98ba956f6a38 ("powerpc/pseries/eeh: Rework device EEH PE determination")
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
index d8fd5f7b2143..cf024fa37bda 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -363,7 +363,6 @@ void pseries_eeh_init_edev(struct pci_dn *pdn)
{
struct eeh_pe pe, *parent;
struct eeh_dev *edev;
- int addr;
u32 pcie_flags;
int ret;
@@ -422,8 +421,8 @@ void pseries_eeh_init_edev(struct pci_dn *pdn)
}
/* first up, find the pe_config_addr for the PE containing the device */
- addr = pseries_eeh_get_pe_config_addr(pdn);
- if (addr < 0) {
+ ret = pseries_eeh_get_pe_config_addr(pdn);
+ if (ret < 0) {
eeh_edev_dbg(edev, "Unable to find pe_config_addr\n");
goto err;
}
@@ -431,7 +430,7 @@ void pseries_eeh_init_edev(struct pci_dn *pdn)
/* Try enable EEH on the fake PE */
memset(&pe, 0, sizeof(struct eeh_pe));
pe.phb = pdn->phb;
- pe.addr = addr;
+ pe.addr = ret;
eeh_edev_dbg(edev, "Enabling EEH on device\n");
ret = eeh_ops->set_option(&pe, EEH_OPT_ENABLE);
@@ -440,7 +439,7 @@ void pseries_eeh_init_edev(struct pci_dn *pdn)
goto err;
}
- edev->pe_config_addr = addr;
+ edev->pe_config_addr = pe.addr;
eeh_add_flag(EEH_ENABLED);
--
2.26.2
^ permalink raw reply related
* [PATCH 1/2] powerpc/eeh: Delete eeh_pe->config_addr
From: Oliver O'Halloran @ 2020-10-07 4:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Oliver O'Halloran
The eeh_pe->config_addr field was supposed to be removed in
commit 35d64734b643 ("powerpc/eeh: Clean up PE addressing") which made it
largely unused. Finish the job.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
---
mpe: the Fixes SHA is from ppc/next, fold it into that if you want.
---
arch/powerpc/include/asm/eeh.h | 1 -
arch/powerpc/kernel/eeh.c | 2 +-
arch/powerpc/kernel/eeh_pe.c | 4 ++--
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index dd6a4ac6c713..b1a5bba2e0b9 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -73,7 +73,6 @@ struct pci_dn;
struct eeh_pe {
int type; /* PE type: PHB/Bus/Device */
int state; /* PE EEH dependent mode */
- int config_addr; /* Traditional PCI address */
int addr; /* PE configuration address */
struct pci_controller *phb; /* Associated PHB */
struct pci_bus *bus; /* Top PCI bus for bus PE */
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 87de8b798b2d..0e160dffcb86 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -466,7 +466,7 @@ int eeh_dev_check_failure(struct eeh_dev *edev)
return 0;
}
- if (!pe->addr && !pe->config_addr) {
+ if (!pe->addr) {
eeh_stats.no_cfg_addr++;
return 0;
}
diff --git a/arch/powerpc/kernel/eeh_pe.c b/arch/powerpc/kernel/eeh_pe.c
index 61b7d4019051..845e024321d4 100644
--- a/arch/powerpc/kernel/eeh_pe.c
+++ b/arch/powerpc/kernel/eeh_pe.c
@@ -354,8 +354,8 @@ int eeh_pe_tree_insert(struct eeh_dev *edev, struct eeh_pe *new_pe_parent)
pr_err("%s: out of memory!\n", __func__);
return -ENOMEM;
}
- pe->addr = edev->pe_config_addr;
- pe->config_addr = edev->bdfn;
+
+ pe->addr = edev->pe_config_addr;
/*
* Put the new EEH PE into hierarchy tree. If the parent
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v5] powerpc/powernv/elog: Fix race while processing OPAL error log event.
From: Michael Ellerman @ 2020-10-07 3:25 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: aneesh.kumar, oohall, hegdevasant
In-Reply-To: <20201006122051.190176-1-mpe@ellerman.id.au>
On Tue, 6 Oct 2020 23:20:51 +1100, Michael Ellerman wrote:
> Every error log reported by OPAL is exported to userspace through a
> sysfs interface and notified using kobject_uevent(). The userspace
> daemon (opal_errd) then reads the error log and acknowledges the error
> log is saved safely to disk. Once acknowledged the kernel removes the
> respective sysfs file entry causing respective resources to be
> released including kobject.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/powernv/elog: Fix race while processing OPAL error log event.
https://git.kernel.org/powerpc/c/aea948bb80b478ddc2448f7359d574387521a52d
cheers
^ permalink raw reply
* Re: [PATCH v4] pseries/hotplug-memory: hot-add: skip redundant LMB lookup
From: Michael Ellerman @ 2020-10-07 3:25 UTC (permalink / raw)
To: Scott Cheloha, linuxppc-dev
Cc: Nathan Lynch, Laurent Dufour, Michal Suchanek, David Hildenbrand,
Rick Lindsley
In-Reply-To: <20200916145122.3408129-1-cheloha@linux.ibm.com>
On Wed, 16 Sep 2020 09:51:22 -0500, Scott Cheloha wrote:
> During memory hot-add, dlpar_add_lmb() calls memory_add_physaddr_to_nid()
> to determine which node id (nid) to use when later calling __add_memory().
>
> This is wasteful. On pseries, memory_add_physaddr_to_nid() finds an
> appropriate nid for a given address by looking up the LMB containing the
> address and then passing that LMB to of_drconf_to_nid_single() to get the
> nid. In dlpar_add_lmb() we get this address from the LMB itself.
>
> [...]
Applied to powerpc/next.
[1/1] pseries/hotplug-memory: hot-add: skip redundant LMB lookup
https://git.kernel.org/powerpc/c/72cdd117c449896c707fc6cfe5b90978160697d0
cheers
^ permalink raw reply
* Re: [PATCH -next] powerpc/papr_scm: Fix warnings about undeclared variable
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: Wang Wensheng, linuxppc-dev
Cc: santosh, aneesh.kumar, linux-kernel, paulus, vaibhav,
dan.j.williams, ira.weiny
In-Reply-To: <20200918085951.44983-1-wangwensheng4@huawei.com>
On Fri, 18 Sep 2020 08:59:51 +0000, Wang Wensheng wrote:
> Build the kernel with 'make C=2':
> arch/powerpc/platforms/pseries/papr_scm.c:825:1: warning: symbol
> 'dev_attr_perf_stats' was not declared. Should it be static?
Applied to powerpc/next.
[1/1] powerpc/papr_scm: Fix warnings about undeclared variable
https://git.kernel.org/powerpc/c/4366337490cbe5a35b50e83755be629a502ec7e2
cheers
^ permalink raw reply
* Re: [PATCH v2 00/11] Optimization to improve CPU online/offline on Powerpc
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: Michael Ellerman, Srikar Dronamraju
Cc: Nathan Lynch, Gautham R Shenoy, Michael Neuling, Peter Zijlstra,
LKML, Nicholas Piggin, Ingo Molnar, Oliver O'Halloran,
Satheesh Rajendran, linuxppc-dev, Valentin Schneider
In-Reply-To: <20200921095653.9701-1-srikar@linux.vnet.ibm.com>
On Mon, 21 Sep 2020 15:26:42 +0530, Srikar Dronamraju wrote:
> Here are some optimizations and fixes to make CPU online/offline
> faster and hence result in faster bootup.
>
> Its based on top of my v5 coregroup support patchset.
> https://lore.kernel.org/linuxppc-dev/20200810071834.92514-1-srikar@linux.vnet.ibm.com/t/#u
>
> Anton reported that his 4096 cpu (1024 cores in a socket) was taking too
> long to boot. He also analyzed that most of the time was being spent on
> updating cpu_core_mask.
>
> [...]
Applied to powerpc/next.
[01/11] powerpc/topology: Update topology_core_cpumask
https://git.kernel.org/powerpc/c/4bce545903fa0290e011cf118997717f0c4f4d20
[02/11] powerpc/smp: Stop updating cpu_core_mask
https://git.kernel.org/powerpc/c/4ca234a9cbd7c3a656b34dd98c8b156f70ed7849
[03/11] powerpc/smp: Remove get_physical_package_id
https://git.kernel.org/powerpc/c/e29e9ed665eeb6f98cd88672994ecf4aaefdb943
[04/11] powerpc/smp: Optimize remove_cpu_from_masks
https://git.kernel.org/powerpc/c/70edd4a7c753ba18e3e4bb9e97b6d85156cea738
[05/11] powerpc/smp: Limit CPUs traversed to within a node.
https://git.kernel.org/powerpc/c/53516d4abacfab1faaa075c1f79957abc3da358c
[06/11] powerpc/smp: Stop passing mask to update_mask_by_l2
https://git.kernel.org/powerpc/c/1f3a4181042107e32e44047e9dde990aced845b5
[07/11] powerpc/smp: Depend on cpu_l1_cache_map when adding CPUs
https://git.kernel.org/powerpc/c/661e3d42f99193b7fdd71467a87e48f6e597c285
[08/11] powerpc/smp: Check for duplicate topologies and consolidate
https://git.kernel.org/powerpc/c/375370a10d061d5c75c6bc5b09c5db4cc0b0fcfe
[09/11] powerpc/smp: Optimize update_mask_by_l2
https://git.kernel.org/powerpc/c/3ab33d6dc3e98e83b55732049e1d1d488207bb6d
[10/11] powerpc/smp: Move coregroup mask updation to a new function
https://git.kernel.org/powerpc/c/b8a97cb4599cda28bd3b3bc13042f5803b42ad65
[11/11] powerpc/smp: Optimize update_coregroup_mask
https://git.kernel.org/powerpc/c/70a94089d7f7fa91bc1795622426b3ed017ec71a
cheers
^ permalink raw reply
* Re: [PATCH v2 1/9] powerpc/eeh: Rework EEH initialisation
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev
In-Reply-To: <20200918093050.37344-1-oohall@gmail.com>
On Fri, 18 Sep 2020 19:30:42 +1000, Oliver O'Halloran wrote:
> Drop the EEH register / unregister ops thing and have the platform pass the
> ops structure into eeh_init() directly. This takes one initcall out of the
> EEH setup path and it means we're only doing EEH setup on the platforms
> which actually support it. It's also less code and generally easier to
> follow.
>
> No functional changes.
Applied to powerpc/next.
[1/9] powerpc/eeh: Rework EEH initialisation
https://git.kernel.org/powerpc/c/d125aedb404204de0579b16028096b2cc09e4deb
[2/9] powerpc/powernv: Stop using eeh_ops->init()
https://git.kernel.org/powerpc/c/82a1ea21f1bac42eb8e3f77d5d249201855f2c85
[3/9] powerpc/pseries: Stop using eeh_ops->init()
https://git.kernel.org/powerpc/c/1f8fa0cd6a848ff072bffe0ee776554387128f60
[4/9] powerpc/eeh: Delete eeh_ops->init
https://git.kernel.org/powerpc/c/5d69e46a2104050c0a458c6bf6abba5f58f56e4c
[5/9] powerpc/eeh: Move EEH initialisation to an arch initcall
https://git.kernel.org/powerpc/c/395ee2a2a15ba1c4c7c414db24dc3082ba8feab8
[6/9] powerpc/pseries/eeh: Clean up pe_config_addr lookups
https://git.kernel.org/powerpc/c/f61c859feb5d19787c93d6b2b3d4beeca7260034
[7/9] powerpc/pseries/eeh: Rework device EEH PE determination
https://git.kernel.org/powerpc/c/98ba956f6a3891b233466b8da064f17d16dc2090
[8/9] powerpc/pseries/eeh: Allow zero to be a valid PE configuration address
https://git.kernel.org/powerpc/c/42de19d5ef71b91765266557705394e52954adb3
[9/9] powerpc/eeh: Clean up PE addressing
https://git.kernel.org/powerpc/c/35d64734b64315f2c5716c5a0a380ed1ba8fbe4a
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc: untangle cputable mce include
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20200916030234.4110379-1-npiggin@gmail.com>
On Wed, 16 Sep 2020 13:02:33 +1000, Nicholas Piggin wrote:
> Having cputable.h include mce.h means it pulls in a bunch of low level
> headers (e.g., synch.h) which then can't use CPU_FTR_ definitions.
Applied to powerpc/next.
[1/2] powerpc: untangle cputable mce include
https://git.kernel.org/powerpc/c/9983efa83b0a98da33807ccf5c047e204fdcac4c
[2/2] powerpc/64s: Add cp_abort after tlbiel to invalidate copy-buffer address
https://git.kernel.org/powerpc/c/05504b42562066ae27ce3e7dcec37f81dea476cb
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: add new branch prediction security bits for link stack
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20200825075612.224656-1-npiggin@gmail.com>
On Tue, 25 Aug 2020 17:56:12 +1000, Nicholas Piggin wrote:
> The hypervisor interface has defined branch prediction security bits for
> handling the link stack. Wire them up.
Applied to powerpc/next.
[1/1] powerpc/pseries: add new branch prediction security bits for link stack
https://git.kernel.org/powerpc/c/cdb1ea0276bd6a225aa1203b4829b8c3c0d4d069
cheers
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/64: fix irq replay missing preempt
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20200915114650.3980244-1-npiggin@gmail.com>
On Tue, 15 Sep 2020 21:46:45 +1000, Nicholas Piggin wrote:
> Prior to commit 3282a3da25bd ("powerpc/64: Implement soft interrupt
> replay in C"), replayed interrupts returned by the regular interrupt
> exit code, which performs preemption in case an interrupt had set
> need_resched.
>
> This logic was missed by the conversion. Adding preempt_disable/enable
> around the interrupt replay and final irq enable will reschedule if
> needed.
Patches 1-5 applied to powerpc/next.
[1/6] powerpc/64: fix irq replay missing preempt
https://git.kernel.org/powerpc/c/903fd31d3212ab72d564c68f6cfb5d04db68773e
[2/6] powerpc/64: fix irq replay pt_regs->softe value
https://git.kernel.org/powerpc/c/2b48e96be2f9f7151197fd25dc41487054bc6f5b
[3/6] powerpc/64e: remove PACA_IRQ_EE_EDGE
https://git.kernel.org/powerpc/c/012a9a97a8fd6c96d5ec64eb0583220490d95e73
[4/6] powerpc/64e: remove 64s specific interrupt soft-mask code
https://git.kernel.org/powerpc/c/903dd1ff453e458fc7608ee4df42a6df16d3d1a0
[5/6] powerpc/64: make restore_interrupts 64e only
https://git.kernel.org/powerpc/c/455575533c7aa294d3c0284d59a77ae9a60c0537
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: switch 85xx defconfigs from legacy ide to libata
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: mpe, Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20200924041310.520970-1-hch@lst.de>
On Thu, 24 Sep 2020 06:13:10 +0200, Christoph Hellwig wrote:
> Switch the 85xx defconfigs from the soon to be removed legacy ide
> driver to libata.
Applied to powerpc/next.
[1/1] powerpc: switch 85xx defconfigs from legacy ide to libata
https://git.kernel.org/powerpc/c/874dc62f548f28649ac3d7e31025b1e8cec3868a
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/tm: Save and restore AMR on treclaim and trechkpt
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: Gustavo Romero, linuxppc-dev; +Cc: aneesh.kumar, mikey
In-Reply-To: <20200919150025.9609-1-gromero@linux.ibm.com>
On Sat, 19 Sep 2020 12:00:25 -0300, Gustavo Romero wrote:
> Althought AMR is stashed in the checkpoint area, currently we don't save
> it to the per thread checkpoint struct after a treclaim and so we don't
> restore it either from that struct when we trechkpt. As a consequence when
> the transaction is later rolled back the kernel space AMR value when the
> trechkpt was done appears in userspace.
>
> That commit saves and restores AMR accordingly on treclaim and trechkpt.
> Since AMR value is also used in kernel space in other functions, it also
> takes care of stashing kernel live AMR into the stack before treclaim and
> before trechkpt, restoring it later, just before returning from tm_reclaim
> and __tm_recheckpoint.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/tm: Save and restore AMR on treclaim and trechkpt
https://git.kernel.org/powerpc/c/d0ffdee8ff01fb21085d835ee54dc8c1c4d19226
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: PPC_SECURE_BOOT should not require PowerNV
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: Daniel Axtens, linuxppc-dev; +Cc: Nayna Jain
In-Reply-To: <20200924014922.172914-1-dja@axtens.net>
On Thu, 24 Sep 2020 11:49:22 +1000, Daniel Axtens wrote:
> In commit 61f879d97ce4 ("powerpc/pseries: Detect secure and trusted
> boot state of the system.") we taught the kernel how to understand the
> secure-boot parameters used by a pseries guest.
>
> However, CONFIG_PPC_SECURE_BOOT still requires PowerNV. I didn't
> catch this because pseries_le_defconfig includes support for
> PowerNV and so everything still worked. Indeed, most configs will.
> Nonetheless, technically PPC_SECURE_BOOT doesn't require PowerNV
> any more.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: PPC_SECURE_BOOT should not require PowerNV
https://git.kernel.org/powerpc/c/5c5e46dad939b2bf4df04293ab9ac68abd7c1f55
cheers
^ permalink raw reply
* Re: [PATCH v3] pseries/hotplug-memory: hot-add: skip redundant LMB lookup
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: Scott Cheloha, linuxppc-dev
Cc: Laurent Dufour, Michal Suchanek, Rick Lindsley, Nathan Lynch,
David Hildenbrand
In-Reply-To: <20200915194647.3334645-1-cheloha@linux.ibm.com>
On Tue, 15 Sep 2020 14:46:47 -0500, Scott Cheloha wrote:
> During memory hot-add, dlpar_add_lmb() calls memory_add_physaddr_to_nid()
> to determine which node id (nid) to use when later calling __add_memory().
>
> This is wasteful. On pseries, memory_add_physaddr_to_nid() finds an
> appropriate nid for a given address by looking up the LMB containing the
> address and then passing that LMB to of_drconf_to_nid_single() to get the
> nid. In dlpar_add_lmb() we get this address from the LMB itself.
>
> [...]
Applied to powerpc/next.
[1/1] pseries/hotplug-memory: hot-add: skip redundant LMB lookup
https://git.kernel.org/powerpc/c/72cdd117c449896c707fc6cfe5b90978160697d0
cheers
^ permalink raw reply
* Re: [PATCH v4] pseries/hotplug-memory: hot-add: skip redundant LMB lookup
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: Scott Cheloha, linuxppc-dev
Cc: Laurent Dufour, Michal Suchanek, Rick Lindsley, Nathan Lynch,
David Hildenbrand
In-Reply-To: <20200916145122.3408129-1-cheloha@linux.ibm.com>
On Wed, 16 Sep 2020 09:51:22 -0500, Scott Cheloha wrote:
> During memory hot-add, dlpar_add_lmb() calls memory_add_physaddr_to_nid()
> to determine which node id (nid) to use when later calling __add_memory().
>
> This is wasteful. On pseries, memory_add_physaddr_to_nid() finds an
> appropriate nid for a given address by looking up the LMB containing the
> address and then passing that LMB to of_drconf_to_nid_single() to get the
> nid. In dlpar_add_lmb() we get this address from the LMB itself.
>
> [...]
Applied to powerpc/next.
[1/1] pseries/hotplug-memory: hot-add: skip redundant LMB lookup
https://git.kernel.org/powerpc/c/72cdd117c449896c707fc6cfe5b90978160697d0
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/rtas: Restrict RTAS requests from userspace
From: Michael Ellerman @ 2020-10-07 3:21 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev; +Cc: nathanl, leobras.c, stable, dja
In-Reply-To: <20200820044512.7543-1-ajd@linux.ibm.com>
On Thu, 20 Aug 2020 14:45:12 +1000, Andrew Donnellan wrote:
> A number of userspace utilities depend on making calls to RTAS to retrieve
> information and update various things.
>
> The existing API through which we expose RTAS to userspace exposes more
> RTAS functionality than we actually need, through the sys_rtas syscall,
> which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
> want with arbitrary arguments.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/rtas: Restrict RTAS requests from userspace
https://git.kernel.org/powerpc/c/bd59380c5ba4147dcbaad3e582b55ccfd120b764
[2/2] selftests/powerpc: Add a rtas_filter selftest
https://git.kernel.org/powerpc/c/dc9af82ea0614bb138705d1f5230d53b3b1dfb83
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox