Re: [PATCH v8 7/7] powerpc: add machine check safe copy_to_user
Michael Ellerman writes:
> Santosh Sivaraj writes:
>> Use memcpy_mcsafe() implementation to define copy_to_user_mcsafe()
>>
>> Signed-off-by: Santosh Sivaraj
>> ---
>> arch/powerpc/Kconfig | 1 +
>> arch/powerpc/include/asm/uaccess.h | 14 ++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 77f6ebf97113..4316e36095a2 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -137,6 +137,7 @@ config PPC
>> select ARCH_HAS_STRICT_KERNEL_RWX if ((PPC_BOOK3S_64 || PPC32) &&
>> !RELOCATABLE && !HIBERNATION)
>> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
>> select ARCH_HAS_UACCESS_FLUSHCACHE if PPC64
>> +select ARCH_HAS_UACCESS_MCSAFE if PPC64
>> select ARCH_HAS_UBSAN_SANITIZE_ALL
>> select ARCH_HAVE_NMI_SAFE_CMPXCHG
>> select ARCH_KEEP_MEMBLOCK
>> diff --git a/arch/powerpc/include/asm/uaccess.h
>> b/arch/powerpc/include/asm/uaccess.h
>> index 8b03eb44e876..15002b51ff18 100644
>> --- a/arch/powerpc/include/asm/uaccess.h
>> +++ b/arch/powerpc/include/asm/uaccess.h
>> @@ -387,6 +387,20 @@ static inline unsigned long raw_copy_to_user(void
>> __user *to,
>> return ret;
>> }
>>
>> +static __always_inline unsigned long __must_check
>> +copy_to_user_mcsafe(void __user *to, const void *from, unsigned long n)
>> +{
>> +if (likely(check_copy_size(from, n, true))) {
>> +if (access_ok(to, n)) {
>> +allow_write_to_user(to, n);
>> +n = memcpy_mcsafe((void *)to, from, n);
>> +prevent_write_to_user(to, n);
>> +}
>> +}
>> +
>> +return n;
>> +}
>
> This looks OK to me.
>
> It would be nice though if copy_to_user_mcsafe() followed the pattern of
> the other copy_to_user() etc. routines where the arch code is only
> responsible for the actual arch details, and all the checks are done in
> the generic code. That would be a good cleanup to do after this has gone
> in, as the 2nd implementation of the API.
Sure, will do that.
>
> cheers
Re: [PATCH v8 3/7] powerpc/mce: Fix MCE handling for huge pages
Mahesh Jagannath Salgaonkar writes:
> On 8/7/19 8:26 PM, Santosh Sivaraj wrote:
>> From: Balbir Singh
>>
>> The current code would fail on huge pages addresses, since the shift would
>> be incorrect. Use the correct page shift value returned by
>> __find_linux_pte() to get the correct physical address. The code is more
>> generic and can handle both regular and compound pages.
>>
>> Fixes: ba41e1e1ccb9 ("powerpc/mce: Hookup derror (load/store) UE errors")
>> Signed-off-by: Balbir Singh
>> [ar...@linux.ibm.com: Fixup pseries_do_memory_failure()]
>> Signed-off-by: Reza Arbab
>> Co-developed-by: Santosh Sivaraj
>> Signed-off-by: Santosh Sivaraj
>> ---
>> arch/powerpc/include/asm/mce.h | 2 +-
>> arch/powerpc/kernel/mce_power.c | 50 ++--
>> arch/powerpc/platforms/pseries/ras.c | 9 ++---
>> 3 files changed, 29 insertions(+), 32 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
>> index a4c6a74ad2fb..f3a6036b6bc0 100644
>> --- a/arch/powerpc/include/asm/mce.h
>> +++ b/arch/powerpc/include/asm/mce.h
>> @@ -209,7 +209,7 @@ extern void release_mce_event(void);
>> extern void machine_check_queue_event(void);
>> extern void machine_check_print_event_info(struct machine_check_event *evt,
>> bool user_mode, bool in_guest);
>> -unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr);
>> +unsigned long addr_to_phys(struct pt_regs *regs, unsigned long addr);
>> #ifdef CONFIG_PPC_BOOK3S_64
>> void flush_and_reload_slb(void);
>> #endif /* CONFIG_PPC_BOOK3S_64 */
>> diff --git a/arch/powerpc/kernel/mce_power.c
>> b/arch/powerpc/kernel/mce_power.c
>> index a814d2dfb5b0..bed38a8e2e50 100644
>> --- a/arch/powerpc/kernel/mce_power.c
>> +++ b/arch/powerpc/kernel/mce_power.c
>> @@ -20,13 +20,14 @@
>> #include
>>
>> /*
>> - * Convert an address related to an mm to a PFN. NOTE: we are in real
>> - * mode, we could potentially race with page table updates.
>> + * Convert an address related to an mm to a physical address.
>> + * NOTE: we are in real mode, we could potentially race with page table
>> updates.
>> */
>> -unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr)
>> +unsigned long addr_to_phys(struct pt_regs *regs, unsigned long addr)
>> {
>> -pte_t *ptep;
>> -unsigned long flags;
>> +pte_t *ptep, pte;
>> +unsigned int shift;
>> +unsigned long flags, phys_addr;
>> struct mm_struct *mm;
>>
>> if (user_mode(regs))
>> @@ -35,14 +36,21 @@ unsigned long addr_to_pfn(struct pt_regs *regs, unsigned
>> long addr)
>> mm = _mm;
>>
>> local_irq_save(flags);
>> -if (mm == current->mm)
>> -ptep = find_current_mm_pte(mm->pgd, addr, NULL, NULL);
>> -else
>> -ptep = find_init_mm_pte(addr, NULL);
>> +ptep = __find_linux_pte(mm->pgd, addr, NULL, );
>> local_irq_restore(flags);
>> +
>> if (!ptep || pte_special(*ptep))
>> return ULONG_MAX;
>> -return pte_pfn(*ptep);
>> +
>> +pte = *ptep;
>> +if (shift > PAGE_SHIFT) {
>> +unsigned long rpnmask = (1ul << shift) - PAGE_SIZE;
>> +
>> +pte = __pte(pte_val(pte) | (addr & rpnmask));
>> +}
>> +phys_addr = pte_pfn(pte) << PAGE_SHIFT;
>> +
>> +return phys_addr;
>> }
>>
>> /* flush SLBs and reload */
>> @@ -354,18 +362,16 @@ static int mce_find_instr_ea_and_pfn(struct pt_regs
>> *regs, uint64_t *addr,
>
> Now that we have addr_to_phys() can we change this function name as well
> to mce_find_instr_ea_and_phys() ?
Makes sense, will avoid confusions.
>
> Tested-by: Mahesh Salgaonkar
>
> This should go to stable tree. Can you move this patch to 2nd position ?
Thanks for testing. Sure. Will reorder and mark stable as well.
Thanks,
Santosh
>
> Thanks,
> -Mahesh.
>
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.3-4 tag
[ expanded Cc ] Linus Torvalds writes: > On Sat, Aug 10, 2019 at 3:11 AM Michael Ellerman wrote: >> >> Just one fix, a revert of a commit that was meant to be a minor improvement >> to >> some inline asm, but ended up having no real benefit with GCC and broke >> booting >> 32-bit machines when using Clang. > > Pulled, but whenever there are possible subtle compiler issues I get > nervous, and wonder if the problem was reported to the clang guys? Yes, sorry I should have included more context. It was actually the Clang Linux folks who noticed it and reported it to us: https://github.com/ClangBuiltLinux/linux/issues/593 There's an LLVM bug filed: https://bugs.llvm.org/show_bug.cgi?id=42762 And I think there's now agreement that the Clang behaviour is not correct, Nick actually sent a revert as well but I already had one queued: https://patchwork.ozlabs.org/patch/1144980/ Arnd identified some work arounds, which we may end up using, but for this cycle we thought it was preferable to just revert this change as it didn't actually change code generation with GCC anyway. cheers
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.3-4 tag
On Sat, Aug 10, 2019 at 10:21:01AM -0700, Linus Torvalds wrote: > On Sat, Aug 10, 2019 at 3:11 AM Michael Ellerman wrote: > > > > Just one fix, a revert of a commit that was meant to be a minor improvement > > to > > some inline asm, but ended up having no real benefit with GCC and broke > > booting > > 32-bit machines when using Clang. > > Pulled, but whenever there are possible subtle compiler issues I get > nervous, and wonder if the problem was reported to the clang guys? > > In particular, if the kernel change was technically correct, maybe > somebody else comes along in a few years and tries the same, and then > it's another odd "why doesn't this work for person X when it works > just fine for me".. > > Linus It was. https://github.com/ClangBuiltLinux/linux/issues/593 https://bugs.llvm.org/show_bug.cgi?id=42762 We're still waiting for input from the PowerPC backend maintainers as that is most likely where this issue originates from. Cheers, Nathan
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.3-4 tag
The pull request you sent on Sat, 10 Aug 2019 20:11:49 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.3-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/23df57afe8eebff6ece05a815934f2f70a851e0a Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH v3] powerpc/fadump: sysfs for fadump memory reservation
Add a sys interface to allow querying the memory reserved by
fadump for saving the crash dump.
Add an ABI doc entry for new sysfs interface.
- /sys/kernel/fadump_mem_reserved
Signed-off-by: Sourabh Jain
---
Changelog:
v1 -> v2:
- Added ABI doc for new sysfs interface.
v2 -> v3:
- Updated the ABI documentation.
---
Documentation/ABI/testing/sysfs-kernel-fadump| 6 ++
Documentation/powerpc/firmware-assisted-dump.rst | 5 +
arch/powerpc/kernel/fadump.c | 14 ++
3 files changed, 25 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-kernel-fadump
diff --git a/Documentation/ABI/testing/sysfs-kernel-fadump
b/Documentation/ABI/testing/sysfs-kernel-fadump
new file mode 100644
index ..ec034939475b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-fadump
@@ -0,0 +1,6 @@
+What: /sys/kernel/fadump_mem_reserved
+Date: August 2019
+Contact: linuxppc-dev@lists.ozlabs.org
+Description: read only
+ Provide information about the amount of memory
+ reserved by fadump to save the crash dump.
diff --git a/Documentation/powerpc/firmware-assisted-dump.rst
b/Documentation/powerpc/firmware-assisted-dump.rst
index 9ca12830a48e..a5dfb20d4dc3 100644
--- a/Documentation/powerpc/firmware-assisted-dump.rst
+++ b/Documentation/powerpc/firmware-assisted-dump.rst
@@ -222,6 +222,11 @@ Here is the list of files under kernel sysfs:
be handled and vmcore will not be captured. This interface can be
easily integrated with kdump service start/stop.
+ /sys/kernel/fadump_mem_reserved
+
+ This is used to display the memory reserved by fadump for saving the
+ crash dump.
+
/sys/kernel/fadump_release_mem
This file is available only when fadump is active during
second kernel. This is used to release the reserved memory
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 4eab97292cc2..cd373d1d4b82 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1514,6 +1514,13 @@ static ssize_t fadump_enabled_show(struct kobject *kobj,
return sprintf(buf, "%d\n", fw_dump.fadump_enabled);
}
+static ssize_t fadump_mem_reserved_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%ld\n", fw_dump.reserve_dump_area_size);
+}
+
static ssize_t fadump_register_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
@@ -1632,6 +1639,9 @@ static struct kobj_attribute fadump_attr =
__ATTR(fadump_enabled,
static struct kobj_attribute fadump_register_attr = __ATTR(fadump_registered,
0644, fadump_register_show,
fadump_register_store);
+static struct kobj_attribute fadump_mem_reserved_attr =
+ __ATTR(fadump_mem_reserved, 0444,
+ fadump_mem_reserved_show, NULL);
DEFINE_SHOW_ATTRIBUTE(fadump_region);
@@ -1663,6 +1673,10 @@ static void fadump_init_files(void)
printk(KERN_ERR "fadump: unable to create sysfs file"
" fadump_release_mem (%d)\n", rc);
}
+ rc = sysfs_create_file(kernel_kobj, _mem_reserved_attr.attr);
+ if (rc)
+ pr_err("unable to create sysfs file fadump_mem_reserved (%d)\n",
+ rc);
return;
}
--
2.17.2
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.3-4 tag
On Sat, Aug 10, 2019 at 3:11 AM Michael Ellerman wrote: > > Just one fix, a revert of a commit that was meant to be a minor improvement to > some inline asm, but ended up having no real benefit with GCC and broke > booting > 32-bit machines when using Clang. Pulled, but whenever there are possible subtle compiler issues I get nervous, and wonder if the problem was reported to the clang guys? In particular, if the kernel change was technically correct, maybe somebody else comes along in a few years and tries the same, and then it's another odd "why doesn't this work for person X when it works just fine for me".. Linus
[Bug 204479] KASAN hit at modprobe zram
https://bugzilla.kernel.org/show_bug.cgi?id=204479 --- Comment #16 from Erhard F. (erhar...@mailbox.org) --- Created attachment 284309 --> https://bugzilla.kernel.org/attachment.cgi?id=284309=edit dmesg (kernel 5.3-rc3 + debug patch + shadow patch + parallel patch, PowerMac G4 DP) Also tested your powerpc-kasan-fix-parallele-loading-of-modules.diff now which seems to work fine! dmesg from the G4 DP with CONFIG_SMP back on is almost identical to non-smp kernel dmesg. raid6 pq reliably oopses. Probably the 1st issue revealed by ppc32 KASAN. ;) Loading the radeon module at boot still freezes the G4. modprobing it later on works, without any special dmesg output, switching display over from Offb to radeonfb. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH v6 1/7] kvmppc: Driver to manage pages of secure guest
On Sat, Aug 10, 2019 at 12:58:19PM +0200, Christoph Hellwig wrote:
>
> > +int kvmppc_devm_init(void)
> > +{
> > + int ret = 0;
> > + unsigned long size;
> > + struct resource *res;
> > + void *addr;
> > +
> > + size = kvmppc_get_secmem_size();
> > + if (!size) {
> > + ret = -ENODEV;
> > + goto out;
> > + }
> > +
> > + ret = alloc_chrdev_region(_devm.devt, 0, 1,
> > + "kvmppc-devm");
> > + if (ret)
> > + goto out;
> > +
> > + dev_set_name(_devm.dev, "kvmppc_devm_device%d", 0);
> > + kvmppc_devm.dev.release = kvmppc_devm_release;
> > + device_initialize(_devm.dev);
> > + res = devm_request_free_mem_region(_devm.dev,
> > + _resource, size);
> > + if (IS_ERR(res)) {
> > + ret = PTR_ERR(res);
> > + goto out_unregister;
> > + }
> > +
> > + kvmppc_devm.pagemap.type = MEMORY_DEVICE_PRIVATE;
> > + kvmppc_devm.pagemap.res = *res;
> > + kvmppc_devm.pagemap.ops = _devm_ops;
> > + addr = devm_memremap_pages(_devm.dev, _devm.pagemap);
> > + if (IS_ERR(addr)) {
> > + ret = PTR_ERR(addr);
> > + goto out_unregister;
> > + }
>
> It seems a little silly to allocate a struct device just so that we can
> pass it to devm_request_free_mem_region and devm_memremap_pages. I think
> we should just create non-dev_ versions of those as well.
There is no reason for us to create a device really. If non-dev versions
of the above two routines are present, I can switch.
I will take care of the rest of your comments. Thanks for the review.
Regards,
Bharata.
Re: [PATCH v6 1/7] kvmppc: Driver to manage pages of secure guest
> +#ifdef CONFIG_PPC_UV
> +extern unsigned long kvmppc_h_svm_page_in(struct kvm *kvm,
> + unsigned long gra,
> + unsigned long flags,
> + unsigned long page_shift);
> +extern unsigned long kvmppc_h_svm_page_out(struct kvm *kvm,
> + unsigned long gra,
> + unsigned long flags,
> + unsigned long page_shift);
No need for externs on function declarations.
> +struct kvmppc_devm_device {
> + struct device dev;
> + dev_t devt;
> + struct dev_pagemap pagemap;
> + unsigned long pfn_first, pfn_last;
> + unsigned long *pfn_bitmap;
> +};
We shouldn't really need this conaining structucture given that there
is only a single global instance of it anyway.
> +struct kvmppc_devm_copy_args {
> + unsigned long *rmap;
> + unsigned int lpid;
> + unsigned long gpa;
> + unsigned long page_shift;
> +};
Do we really need this args structure? It is just used in a single
function call where passing the arguments might be cleaner.
> +static void kvmppc_devm_put_page(struct page *page)
> +{
> + unsigned long pfn = page_to_pfn(page);
> + unsigned long flags;
> + struct kvmppc_devm_page_pvt *pvt;
> +
> + spin_lock_irqsave(_devm_lock, flags);
> + pvt = (struct kvmppc_devm_page_pvt *)page->zone_device_data;
No need for the cast.
> + page->zone_device_data = 0;
This should be NULL.
> +
> + bitmap_clear(kvmppc_devm.pfn_bitmap,
> + pfn - kvmppc_devm.pfn_first, 1);
> + *(pvt->rmap) = 0;
No need for the braces.
> + dpage = alloc_page_vma(GFP_HIGHUSER, mig->vma, mig->start);
> + if (!dpage)
> + return -EINVAL;
> + lock_page(dpage);
> + pvt = (struct kvmppc_devm_page_pvt *)spage->zone_device_data;
No need for the cast here.
> +static void kvmppc_devm_page_free(struct page *page)
> +{
> + kvmppc_devm_put_page(page);
> +}
This seems to be the only caller of kvmppc_devm_put_page, any reason
not to just merge the two functions?
> +static int kvmppc_devm_pages_init(void)
> +{
> + unsigned long nr_pfns = kvmppc_devm.pfn_last -
> + kvmppc_devm.pfn_first;
> +
> + kvmppc_devm.pfn_bitmap = kcalloc(BITS_TO_LONGS(nr_pfns),
> + sizeof(unsigned long), GFP_KERNEL);
> + if (!kvmppc_devm.pfn_bitmap)
> + return -ENOMEM;
> +
> + spin_lock_init(_devm_lock);
Just initialize the spinlock using DEFINE_SPINLOCK() at compile time.
The rest of the function is so trivial that it can be inlined into the
caller.
Also is kvmppc_devm_lock such a good name? This mostly just protects
the allocation bitmap, so reflecting that in the name might be a good
idea.
> +int kvmppc_devm_init(void)
> +{
> + int ret = 0;
> + unsigned long size;
> + struct resource *res;
> + void *addr;
> +
> + size = kvmppc_get_secmem_size();
> + if (!size) {
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + ret = alloc_chrdev_region(_devm.devt, 0, 1,
> + "kvmppc-devm");
> + if (ret)
> + goto out;
> +
> + dev_set_name(_devm.dev, "kvmppc_devm_device%d", 0);
> + kvmppc_devm.dev.release = kvmppc_devm_release;
> + device_initialize(_devm.dev);
> + res = devm_request_free_mem_region(_devm.dev,
> + _resource, size);
> + if (IS_ERR(res)) {
> + ret = PTR_ERR(res);
> + goto out_unregister;
> + }
> +
> + kvmppc_devm.pagemap.type = MEMORY_DEVICE_PRIVATE;
> + kvmppc_devm.pagemap.res = *res;
> + kvmppc_devm.pagemap.ops = _devm_ops;
> + addr = devm_memremap_pages(_devm.dev, _devm.pagemap);
> + if (IS_ERR(addr)) {
> + ret = PTR_ERR(addr);
> + goto out_unregister;
> + }
It seems a little silly to allocate a struct device just so that we can
pass it to devm_request_free_mem_region and devm_memremap_pages. I think
we should just create non-dev_ versions of those as well.
> +
> + kvmppc_devm.pfn_first = res->start >> PAGE_SHIFT;
> + kvmppc_devm.pfn_last = kvmppc_devm.pfn_first +
> + (resource_size(res) >> PAGE_SHIFT);
pfn_last is only used to calculat a size. Also I think we could
just use kvmppc_devm.pagemap.res directly instead of copying these
values out. the ">> PAGE_SHIFT" is cheap enough.
Re: [PATCH] powerpc/rtas: unexport rtas_online_cpus_mask, rtas_offline_cpus_mask
On Thu, 2019-07-18 at 16:22:14 UTC, Nathan Lynch wrote:
> These aren't used by modular code, nor should they be.
>
> Fixes: 120496ac2d2d ("powerpc: Bring all threads online prior to
> migration/hibernation")
> Signed-off-by: Nathan Lynch
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ae2e953fdca791270e80c08d6a830d9aa472a111
cheers
Re: [PATCH v2] powerpc/powernv: Restrict OPAL symbol map to only be readable by root
On Fri, 2019-05-03 at 07:52:53 UTC, Andrew Donnellan wrote:
> Currently the OPAL symbol map is globally readable, which seems bad as it
> contains physical addresses.
>
> Restrict it to root.
>
> Suggested-by: Michael Ellerman
> Cc: Jordan Niethe
> Cc: Stewart Smith
> Fixes: c8742f85125d ("powerpc/powernv: Expose OPAL firmware symbol map")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andrew Donnellan
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e7de4f7b64c23e503a8c42af98d56f2a7462bd6d
cheers
Re: [PATCH] powerpc/64s: Make boot look nice(r)
On Thu, 2019-05-16 at 02:04:37 UTC, Nicholas Piggin wrote: > Radix boot looks like this: > > - > phys_mem_size = 0x2 > dcache_bsize = 0x80 > icache_bsize = 0x80 > cpu_features = 0xc06f8f5fb1a7 >possible= 0xfbffcf5fb1a7 >always = 0x0003800081a1 > cpu_user_features = 0xdc0065c2 0xaee0 > mmu_features = 0xbc006041 > firmware_features = 0x1000 > hash-mmu: ppc64_pft_size= 0x0 > hash-mmu: kernel vmalloc start = 0xc008 > hash-mmu: kernel IO start= 0xc00a > hash-mmu: kernel vmemmap start = 0xc00c > - > > Fix: > > - > phys_mem_size = 0x2 > dcache_bsize = 0x80 > icache_bsize = 0x80 > cpu_features = 0xc06f8f5fb1a7 >possible= 0xfbffcf5fb1a7 >always = 0x0003800081a1 > cpu_user_features = 0xdc0065c2 0xaee0 > mmu_features = 0xbc006041 > firmware_features = 0x1000 > vmalloc start = 0xc008 > IO start = 0xc00a > vmemmap start = 0xc00c > - > > Signed-off-by: Nicholas Piggin Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/a26c29a00f20015a30e618caf7c0720a351e1d03 cheers
Re: [PATCH v2 1/5] powerpc/powernv: Move SCOM access code into powernv platform
On Thu, 2019-05-09 at 05:11:15 UTC, Andrew Donnellan wrote: > The powernv platform is the only one that directly accesses SCOMs. Move the > support code to platforms/powernv, and get rid of the PPC_SCOM Kconfig > option, as SCOM support is always selected when compiling for powernv. > > This also means that the Kconfig item for CONFIG_SCOM_DEBUGFS will actually > show up in menuconfig, as previously it was the only labelled option in > sysdev/Kconfig and wasn't actually in a menu. > > Signed-off-by: Andrew Donnellan Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/08a456aa643776757e07adfdebe7f7681117d144 cheers
Re: [PATCH v2] powerpc/32: activate ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE
On Wed, 2019-07-31 at 06:31:41 UTC, Christophe Leroy wrote: > PPC32 also have flush_dcache_range() so it can also support > ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE without changes. > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/461cef2a676e7c578d0ef62969dbcb8237c8631d cheers
Re: [PATCH] powerpc/xive: Update comment referencing magic loads from an ESB
On Fri, 2019-08-02 at 00:08:35 UTC, Jordan Niethe wrote:
> The comment above xive_esb_read() references magic loads from an ESB as
> described xive.h. This has been inaccurate since commit 12c1f339cd49
> ("powerpc/xive: Move definition of ESB bits") which moved the
> description. Update the comment to reference the new location of the
> description in xive-regs.h
>
> Signed-off-by: Jordan Niethe
> Acked-by: Stewart Smith
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1ebe0dcce1750109181d666394b7dfd9af9ff645
cheers
Re: [PATCH 1/1] pseries/hotplug-memory.c: Replace nested ifs by switch-case
On Thu, 2019-08-01 at 22:52:51 UTC, Leonardo Bras wrote: > I noticed these nested ifs can be easily replaced by switch-cases, > which can improve readability. > > Signed-off-by: Leonardo Bras > Reviewed-by: David Hildenbrand Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/9616dda1aaddb2080122aaeab96ad7fc064e36b4 cheers
Re: [PATCH 1/2] powerpc/xive: Use GFP_KERNEL instead of GFP_ATOMIC in 'xive_irq_bitmap_add()'
On Thu, 2019-08-01 at 08:32:31 UTC, Christophe JAILLET wrote: > There is no need to use GFP_ATOMIC here. GFP_KERNEL should be enough. > GFP_KERNEL is also already used for another allocation just a few lines > below. > > Signed-off-by: Christophe JAILLET > Reviewed-by: Cédric Le Goater > Reviewed-by: Greg Kurz Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/2705ec100b46390851542fa97e920cc21ffaac4f cheers
Re: [PATCH] powerpc/powernv: Print helpful message when cores guarded
On Thu, 2019-08-01 at 05:16:30 UTC, Joel Stanley wrote: > Often the firmware will guard out cores after a crash. This often > undesirable, and is not immediately noticeable. > > This adds an informative message when a CPU device tree nodes are marked > bad in the device tree. > > Signed-off-by: Joel Stanley Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/680d00741838b1c1bd59d5d7ac96791f5558e05d cheers
Re: [PATCH v2] PCI: rpaphp: Avoid a sometimes-uninitialized warning
On Mon, 2019-06-03 at 22:11:58 UTC, Nathan Chancellor wrote:
> When building with -Wsometimes-uninitialized, clang warns:
>
> drivers/pci/hotplug/rpaphp_core.c:243:14: warning: variable 'fndit' is
> used uninitialized whenever 'for' loop exits because its condition is
> false [-Wsometimes-uninitialized]
> for (j = 0; j < entries; j++) {
> ^~~
> drivers/pci/hotplug/rpaphp_core.c:256:6: note: uninitialized use occurs
> here
> if (fndit)
> ^
> drivers/pci/hotplug/rpaphp_core.c:243:14: note: remove the condition if
> it is always true
> for (j = 0; j < entries; j++) {
> ^~~
> drivers/pci/hotplug/rpaphp_core.c:233:14: note: initialize the variable
> 'fndit' to silence this warning
> int j, fndit;
> ^
> = 0
>
> fndit is only used to gate a sprintf call, which can be moved into the
> loop to simplify the code and eliminate the local variable, which will
> fix this warning.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/504
> Fixes: 2fcf3ae508c2 ("hotplug/drc-info: Add code to search ibm,drc-info
> property")
> Suggested-by: Nick Desaulniers
> Signed-off-by: Nathan Chancellor
> Acked-by: Tyrel Datwyler
> Acked-by: Joel Savitz
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0df3e42167caaf9f8c7b64de3da40a459979afe8
cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-5.3-4 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull another powerpc fix for 5.3: The following changes since commit d7e23b887f67178c4f840781be7a6aa6aeb52ab1: powerpc/kasan: fix early boot failure on PPC32 (2019-07-31 22:02:52 +1000) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.3-4 for you to fetch changes up to ed4289e8b48845888ee46377bd2b55884a55e60b: Revert "powerpc: slightly improve cache helpers" (2019-07-31 22:56:27 +1000) - -- powerpc fixes for 5.3 #4 Just one fix, a revert of a commit that was meant to be a minor improvement to some inline asm, but ended up having no real benefit with GCC and broke booting 32-bit machines when using Clang. Thanks to: Arnd Bergmann, Christophe Leroy, Nathan Chancellor, Nick Desaulniers, Segher Boessenkool. - -- Michael Ellerman (1): Revert "powerpc: slightly improve cache helpers" arch/powerpc/include/asm/cache.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl1OmC4ACgkQUevqPMjh pYBuKw/9H4ZMZpetAqOfJgfpByyhXlNRFriW1QS+KkMjjI60ZY1QYwZNFhZsUs8P chpAvGnLv6zuJafOQ1hlxFa7wc70LTc/RRDRwWPFdtWdDl54OB3YvwFP2do2b/7D gDtqCRMWTgtWdLx7ZpDk3qSN2mDxPRss//FO/UqtkTzNWh2LsQr9sbTZHc0BsIa/ VAyEZSGeFMkUBHjuCKoqyMZAc0aBk7HmJ4LN8zFGH6CtY05c1TBA4rN0qBnGBQI9 upNUgwbG2/vVS3t5YgHzHbrC8KfX+/8Oqo6ePLVlH39g0+wvp6avTeZDwrA7ZHtR wNzHBxlLIpphOSRDr/fQk6yd69rVVbK14DZk3UHaz2qqyBkj3LxlRHKFIYWmPwoi 6E01ovThjSiHyxN1oPJfI1TXmhualhOlER9RTHPYsA20SnFYqAwH+TCydzuhvwAO ueWSqKjK7O+KNhR1QJ3PGD6LIUWiPLMBG0a860Jg9oJ28/X5ZU/UqxBunoYUyQg+ u5bBViUtMkD8d7LEfQjvHSW9IpIRA/N2Y5cHTtmQxPEgspI/t/jXAxLEgkOBVkS2 kJoljNsTNFfKnyTD4v7zh5AABZquy5kyGLFBywQuloJ/7Jc4U3rBOqvRQ+f55E3s naAU0Pf27Bob6VKKNPVeWP5OhPuYZ8YXHnvZ/fpcrYpA/k+xYsg= =Dzq1 -END PGP SIGNATURE-
Re: [PATCH v8 7/7] powerpc: add machine check safe copy_to_user
Santosh Sivaraj writes:
> Use memcpy_mcsafe() implementation to define copy_to_user_mcsafe()
>
> Signed-off-by: Santosh Sivaraj
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/uaccess.h | 14 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 77f6ebf97113..4316e36095a2 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -137,6 +137,7 @@ config PPC
> select ARCH_HAS_STRICT_KERNEL_RWX if ((PPC_BOOK3S_64 || PPC32) &&
> !RELOCATABLE && !HIBERNATION)
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> select ARCH_HAS_UACCESS_FLUSHCACHE if PPC64
> + select ARCH_HAS_UACCESS_MCSAFE if PPC64
> select ARCH_HAS_UBSAN_SANITIZE_ALL
> select ARCH_HAVE_NMI_SAFE_CMPXCHG
> select ARCH_KEEP_MEMBLOCK
> diff --git a/arch/powerpc/include/asm/uaccess.h
> b/arch/powerpc/include/asm/uaccess.h
> index 8b03eb44e876..15002b51ff18 100644
> --- a/arch/powerpc/include/asm/uaccess.h
> +++ b/arch/powerpc/include/asm/uaccess.h
> @@ -387,6 +387,20 @@ static inline unsigned long raw_copy_to_user(void __user
> *to,
> return ret;
> }
>
> +static __always_inline unsigned long __must_check
> +copy_to_user_mcsafe(void __user *to, const void *from, unsigned long n)
> +{
> + if (likely(check_copy_size(from, n, true))) {
> + if (access_ok(to, n)) {
> + allow_write_to_user(to, n);
> + n = memcpy_mcsafe((void *)to, from, n);
> + prevent_write_to_user(to, n);
> + }
> + }
> +
> + return n;
> +}
This looks OK to me.
It would be nice though if copy_to_user_mcsafe() followed the pattern of
the other copy_to_user() etc. routines where the arch code is only
responsible for the actual arch details, and all the checks are done in
the generic code. That would be a good cleanup to do after this has gone
in, as the 2nd implementation of the API.
cheers
Re: [PATCH v3] Revert "powerpc: slightly improve cache helpers"
Nick Desaulniers writes: > This reverts commit 6c5875843b87c3adea2beade9d1b8b3d4523900a. > > Work around Clang bug preventing ppc32 from booting. > > Link: https://bugs.llvm.org/show_bug.cgi?id=42762 > Link: https://github.com/ClangBuiltLinux/linux/issues/593 > Debugged-by: Nathan Chancellor > Reported-by: Nathan Chancellor > Reported-by: kbuild test robot > Suggested-by: Christophe Leroy > Signed-off-by: Nick Desaulniers > --- > Changes V2 -> V3: > * Just revert, as per Christophe. > Changes V1 -> V2: > * Change to ouput paremeter. Thanks. I actually already had this revert in my tree since ~10 days ago, but hadn't pushed it yet because the discussion was ongoing. So I'll just use that version, and ask Linus to pull it. cheers
Re: [PATCH v4 0/6] Remove x86-specific code from generic headers
On Fri, Aug 09, 2019 at 10:51:41PM +1000, m...@ellerman.id.au wrote: > I need to take this series via the powerpc tree because there is another > fairly large powerpc specific series dependent on it. > > I think this series already has pretty much all the acks it needs, which > almost never happens, amazing work! > > I'll put the series in a topic branch, just in case there's any bad > conflicts and other folks want to merge it later on. I'll then merge the > topic branch into my next, and so this series will be tested in > linux-next that way. Sounds good to me, I don't expect conflicts from the dma-mapping tree.
