* Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
From: Will Deacon @ 2021-03-29 10:07 UTC (permalink / raw)
To: Daniel Walker
Cc: Rob Herring, Daniel Gimpelevich, X86 ML, open list:MIPS,
linux-kernel@vger.kernel.org, Paul Mackerras, xe-linux-external,
Andrew Morton, linuxppc-dev
In-Reply-To: <20210325195956.GM109100@zorba>
On Thu, Mar 25, 2021 at 12:59:56PM -0700, Daniel Walker wrote:
> On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote:
> >
> > Ok, so you agree we don't need to provide two CMDLINE, one to be appended and one to be prepended.
> >
> > Let's only provide once CMDLINE as of today, and ask the user to select
> > whether he wants it appended or prepended or replacee. Then no need to
> > change all existing config to rename CONFIG_CMDLINE into either of the new
> > ones.
> >
> > That's the main difference between my series and Daniel's series. So I'll
> > finish taking Will's comment into account and we'll send out a v3 soon.
>
> It doesn't solve the needs of Cisco, I've stated many times your changes have
> little value. Please stop submitting them.
FWIW, they're useful for arm64 and I will gladly review the updated series.
I don't think asking people to stop submitting patches is ever the right
answer. Please don't do that.
Will
^ permalink raw reply
* [PATCH] powerpc/papr_scm: Mark nvdimm as unarmed if needed during probe
From: Vaibhav Jain @ 2021-03-29 11:31 UTC (permalink / raw)
To: linux-nvdimm, linuxppc-dev
Cc: Santosh Sivaraj, Shivaprasad G Bhat, Aneesh Kumar K . V,
Vaibhav Jain, Dan Williams, Ira Weiny
In case an nvdimm is found to be unarmed during probe then set its
NDD_UNARMED flag before nvdimm_create(). This would enforce a
read-only access to the ndimm region. Presently even if an nvdimm is
unarmed its not marked as read-only on ppc64 guests.
The patch updates papr_scm_nvdimm_init() to force query of nvdimm
health via __drc_pmem_query_health() and if nvdimm is found to be
unarmed then set the nvdimm flag ND_UNARMED for nvdimm_create().
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
arch/powerpc/platforms/pseries/papr_scm.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index 835163f54244..7e8168e19427 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -914,6 +914,15 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
dimm_flags = 0;
set_bit(NDD_LABELING, &dimm_flags);
+ /*
+ * Check if the nvdimm is unarmed. No locking needed as we are still
+ * initializing. Ignore error encountered if any.
+ */
+ __drc_pmem_query_health(p);
+
+ if (p->health_bitmap & PAPR_PMEM_UNARMED_MASK)
+ set_bit(NDD_UNARMED, &dimm_flags);
+
p->nvdimm = nvdimm_create(p->bus, p, papr_nd_attr_groups,
dimm_flags, PAPR_SCM_DIMM_CMD_MASK, 0, NULL);
if (!p->nvdimm) {
--
2.30.2
^ permalink raw reply related
* Re: [PATCH 00/30] DMA: Mundane typo fixes
From: Greg KH @ 2021-03-29 11:48 UTC (permalink / raw)
To: Bhaskar Chowdhury, Christoph Hellwig, Linus Torvalds, dmaengine,
dri-devel, iommu, linuxppc-dev, dave.jiang, dan.j.williams,
rdunlap, linux-kernel
In-Reply-To: <YGFrvwX8QngvwPbA@Gentoo>
On Mon, Mar 29, 2021 at 11:25:11AM +0530, Bhaskar Chowdhury wrote:
> On 07:29 Mon 29 Mar 2021, Christoph Hellwig wrote:
> > I really don't think these typo patchbomb are that useful. I'm all
> > for fixing typos when working with a subsystem, but I'm not sure these
> > patchbombs help anything.
> >
> I am sure you are holding the wrong end of the wand and grossly failing to
> understand.
Please stop statements like this, it is not helpful and is doing nothing
but ensure that your patches will not be looked at in the future.
> Anyway, I hope I give a heads up ...find "your way" to fix those damn
> thing...it's glaring....
There is no requirement that anyone accept patches that are sent to
them. When you complain when receiving comments on them, that
shows you do not wish to work with others.
Sorry, but you are now on my local blacklist for a while, and I
encourage other maintainers to just ignore these patches as well.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] powerpc/64s: power4 nap fixup in C
From: Andreas Schwab @ 2021-03-29 11:56 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <236a67a4-1609-5fec-3c68-41db02cd1a4c__18973.8760514714$1617008745$gmane$org@csgroup.eu>
On Mär 29 2021, Christophe Leroy wrote:
> Le 29/03/2021 à 10:33, Benjamin Herrenschmidt a écrit :
>> On Fri, 2021-03-12 at 11:20 +1000, Nicholas Piggin wrote:
>>>
>>> +static inline void nap_adjust_return(struct pt_regs *regs)
>>>
>>> +{
>>>
>>> +#ifdef CONFIG_PPC_970_NAP
>>>
>>> + if (unlikely(test_thread_local_flags(_TLF_NAPPING))) {
>>> + /* Can avoid a test-and-clear because NMIs do not call this */
>>> + clear_thread_local_flags(_TLF_NAPPING);
>>> + regs->nip = (unsigned long)power4_idle_nap_return;
>>> + }
>> Is this a pointer to a function descriptor or the actual code ?
>>
>
> --- a/arch/powerpc/kernel/idle_book3s.S
> +++ b/arch/powerpc/kernel/idle_book3s.S
> @@ -209,4 +209,8 @@ _GLOBAL(power4_idle_nap)
> mtmsrd r7
> isync
> b 1b
> +
> + .globl power4_idle_nap_return
> +power4_idle_nap_return:
> + blr
> #endif
The problem is not the definition, it is the reference. In C, a
function symbol always resolves to the address of the descriptor.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 00/30] DMA: Mundane typo fixes
From: Bhaskar Chowdhury @ 2021-03-29 12:57 UTC (permalink / raw)
To: Greg KH
Cc: dave.jiang, Linus Torvalds, rdunlap, linux-kernel, dri-devel,
iommu, dmaengine, dan.j.williams, linuxppc-dev, Christoph Hellwig
In-Reply-To: <YGG+l1EfRuWp0J3A@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]
On 13:48 Mon 29 Mar 2021, Greg KH wrote:
>On Mon, Mar 29, 2021 at 11:25:11AM +0530, Bhaskar Chowdhury wrote:
>> On 07:29 Mon 29 Mar 2021, Christoph Hellwig wrote:
>> > I really don't think these typo patchbomb are that useful. I'm all
>> > for fixing typos when working with a subsystem, but I'm not sure these
>> > patchbombs help anything.
>> >
>> I am sure you are holding the wrong end of the wand and grossly failing to
>> understand.
>
>Please stop statements like this, it is not helpful and is doing nothing
>but ensure that your patches will not be looked at in the future.
>
Greg, don't you think you are bit harsh and have an one sided view? People can
say in better way if they don't like some work. I Have always try to get
along.
>> Anyway, I hope I give a heads up ...find "your way" to fix those damn
>> thing...it's glaring....
>
>There is no requirement that anyone accept patches that are sent to
>them. When you complain when receiving comments on them, that
>shows you do not wish to work with others.
>
Unfortunate you are only seeing my complains...I don't know why you are so
blindfolded.
>Sorry, but you are now on my local blacklist for a while, and I
>encourage other maintainers to just ignore these patches as well.
>
I can not overrule that ...I know my pathes are trivial ..but it seems some
other problems are looming large.
NOT good Greg....not good seriously.
>thanks,
>
>greg k-h
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/mm/book3s64: Use the correct storage key value when calling H_PROTECT
From: Michael Ellerman @ 2021-03-29 13:40 UTC (permalink / raw)
To: linuxppc-dev, Aneesh Kumar K.V, mpe; +Cc: Murilo Opsfelder Araujo
In-Reply-To: <20210326070755.304625-1-aneesh.kumar@linux.ibm.com>
On Fri, 26 Mar 2021 12:37:55 +0530, Aneesh Kumar K.V wrote:
> H_PROTECT expect the flag value to include
> flags: AVPN, pp0, pp1, pp2, key0-key4, Noexec, CMO Option flags
>
> This patch updates hpte_updatepp() to fetch the storage key value from the linux page
> table and use the same in H_PROTECT hcall.
>
> native_hpte_updatepp() is not updated because the kernel doesn't clear the existing
> storage key value there. The kernel also doesn't use hpte_updatepp() callback for
> updating storage keys.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/mm/book3s64: Use the correct storage key value when calling H_PROTECT
https://git.kernel.org/powerpc/c/53f1d31708f6240e4615b0927df31f182e389e2f
cheers
^ permalink raw reply
* Re: [PATCH next v1 2/3] printk: remove safe buffers
From: John Ogness @ 2021-03-29 15:10 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, Peter Zijlstra, Paul Mackerras, Tiezhu Yang,
Rafael Aquini, Alexey Kardashevskiy, Yue Hu, Jordan Niethe,
Kees Cook, Paul E. McKenney, Alistair Popple,
Guilherme G. Piccoli, Nicholas Piggin, Steven Rostedt,
Thomas Gleixner, kexec, linux-kernel, Sergey Senozhatsky,
Eric Biederman, Andrew Morton, linuxppc-dev,
Cédric Le Goater
In-Reply-To: <YGGmNu5ilDnSKH3g@alley>
On 2021-03-29, Petr Mladek <pmladek@suse.com> wrote:
> I wonder if some console drivers rely on the fact that the write()
> callback is called with interrupts disabled.
>
> IMHO, it would be a bug when any write() callback expects that
> callers disabled the interrupts.
Agreed.
> Do you plan to remove the console-spinning stuff after offloading
> consoles to the kthreads?
Yes. Although a similar concept will be introduced to allow the threaded
printers and the atomic consoles to compete.
> Will you call console write() callback with irq enabled from the
> kthread?
No. That defeats the fundamental purpose of this entire rework
excercise. ;-)
> Anyway, we should at least add a comment why the interrupts are
> disabled.
I decided to move the local_irq_save/restore inside the console-spinning
functions and added a comment for v2.
John Ogness
^ permalink raw reply
* Re: [PATCH next v1 2/3] printk: remove safe buffers
From: John Ogness @ 2021-03-29 15:13 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, Peter Zijlstra, Paul Mackerras, Tiezhu Yang,
Rafael Aquini, Alexey Kardashevskiy, Yue Hu, Jordan Niethe,
Kees Cook, Paul E. McKenney, Alistair Popple,
Guilherme G. Piccoli, Nicholas Piggin, Steven Rostedt,
Thomas Gleixner, kexec, linux-kernel, Sergey Senozhatsky,
Eric Biederman, Andrew Morton, linuxppc-dev,
Cédric Le Goater
In-Reply-To: <87sg4e6lo5.fsf@jogness.linutronix.de>
On 2021-03-29, John Ogness <john.ogness@linutronix.de> wrote:
>> Will you call console write() callback with irq enabled from the
>> kthread?
>
> No. That defeats the fundamental purpose of this entire rework
> excercise. ;-)
Sorry, I misread your question. The answer is "yes". We want to avoid a
local_irq_save() when calling into console->write().
John Ogness
^ permalink raw reply
* Re: [PATCH] powerpc/vdso: Separate vvar vma from vdso
From: Laurent Dufour @ 2021-03-29 15:14 UTC (permalink / raw)
To: Dmitry Safonov, linux-kernel
Cc: Dmitry Safonov, Andrei Vagin, Paul Mackerras, stable,
Andy Lutomirski, linuxppc-dev
In-Reply-To: <20210326191720.138155-1-dima@arista.com>
Le 26/03/2021 à 20:17, Dmitry Safonov a écrit :
> Since commit 511157ab641e ("powerpc/vdso: Move vdso datapage up front")
> VVAR page is in front of the VDSO area. In result it breaks CRIU
> (Checkpoint Restore In Userspace) [1], where CRIU expects that "[vdso]"
> from /proc/../maps points at ELF/vdso image, rather than at VVAR data page.
> Laurent made a patch to keep CRIU working (by reading aux vector).
> But I think it still makes sence to separate two mappings into different
> VMAs. It will also make ppc64 less "special" for userspace and as
> a side-bonus will make VVAR page un-writable by debugger (which previously
> would COW page and can be unexpected).
>
> I opportunistically Cc stable on it: I understand that usually such
> stuff isn't a stable material, but that will allow us in CRIU have
> one workaround less that is needed just for one release (v5.11) on
> one platform (ppc64), which we otherwise have to maintain.
> I wouldn't go as far as to say that the commit 511157ab641e is ABI
> regression as no other userspace got broken, but I'd really appreciate
> if it gets backported to v5.11 after v5.12 is released, so as not
> to complicate already non-simple CRIU-vdso code. Thanks!
>
> Cc: Andrei Vagin <avagin@gmail.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Laurent Dufour <ldufour@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: stable@vger.kernel.org # v5.11
> [1]: https://github.com/checkpoint-restore/criu/issues/1417
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
I run the CRIU's test suite and except the usual suspects, all the tests passed.
Tested-by: Laurent Dufour <ldufour@linux.ibm.com>
> ---
> arch/powerpc/include/asm/mmu_context.h | 2 +-
> arch/powerpc/kernel/vdso.c | 54 +++++++++++++++++++-------
> 2 files changed, 40 insertions(+), 16 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
> index 652ce85f9410..4bc45d3ed8b0 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -263,7 +263,7 @@ extern void arch_exit_mmap(struct mm_struct *mm);
> static inline void arch_unmap(struct mm_struct *mm,
> unsigned long start, unsigned long end)
> {
> - unsigned long vdso_base = (unsigned long)mm->context.vdso - PAGE_SIZE;
> + unsigned long vdso_base = (unsigned long)mm->context.vdso;
>
> if (start <= vdso_base && vdso_base < end)
> mm->context.vdso = NULL;
> diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
> index e839a906fdf2..b14907209822 100644
> --- a/arch/powerpc/kernel/vdso.c
> +++ b/arch/powerpc/kernel/vdso.c
> @@ -55,10 +55,10 @@ static int vdso_mremap(const struct vm_special_mapping *sm, struct vm_area_struc
> {
> unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
>
> - if (new_size != text_size + PAGE_SIZE)
> + if (new_size != text_size)
> return -EINVAL;
>
> - current->mm->context.vdso = (void __user *)new_vma->vm_start + PAGE_SIZE;
> + current->mm->context.vdso = (void __user *)new_vma->vm_start;
>
> return 0;
> }
> @@ -73,6 +73,10 @@ static int vdso64_mremap(const struct vm_special_mapping *sm, struct vm_area_str
> return vdso_mremap(sm, new_vma, &vdso64_end - &vdso64_start);
> }
>
> +static struct vm_special_mapping vvar_spec __ro_after_init = {
> + .name = "[vvar]",
> +};
> +
> static struct vm_special_mapping vdso32_spec __ro_after_init = {
> .name = "[vdso]",
> .mremap = vdso32_mremap,
> @@ -89,11 +93,11 @@ static struct vm_special_mapping vdso64_spec __ro_after_init = {
> */
> static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
> {
> - struct mm_struct *mm = current->mm;
> + unsigned long vdso_size, vdso_base, mappings_size;
> struct vm_special_mapping *vdso_spec;
> + unsigned long vvar_size = PAGE_SIZE;
> + struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma;
> - unsigned long vdso_size;
> - unsigned long vdso_base;
>
> if (is_32bit_task()) {
> vdso_spec = &vdso32_spec;
> @@ -110,8 +114,8 @@ static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_int
> vdso_base = 0;
> }
>
> - /* Add a page to the vdso size for the data page */
> - vdso_size += PAGE_SIZE;
> + mappings_size = vdso_size + vvar_size;
> + mappings_size += (VDSO_ALIGNMENT - 1) & PAGE_MASK;
>
> /*
> * pick a base address for the vDSO in process space. We try to put it
> @@ -119,9 +123,7 @@ static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_int
> * and end up putting it elsewhere.
> * Add enough to the size so that the result can be aligned.
> */
> - vdso_base = get_unmapped_area(NULL, vdso_base,
> - vdso_size + ((VDSO_ALIGNMENT - 1) & PAGE_MASK),
> - 0, 0);
> + vdso_base = get_unmapped_area(NULL, vdso_base, mappings_size, 0, 0);
> if (IS_ERR_VALUE(vdso_base))
> return vdso_base;
>
> @@ -133,7 +135,13 @@ static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_int
> * install_special_mapping or the perf counter mmap tracking code
> * will fail to recognise it as a vDSO.
> */
> - mm->context.vdso = (void __user *)vdso_base + PAGE_SIZE;
> + mm->context.vdso = (void __user *)vdso_base + vvar_size;
> +
> + vma = _install_special_mapping(mm, vdso_base, vvar_size,
> + VM_READ | VM_MAYREAD | VM_IO |
> + VM_DONTDUMP | VM_PFNMAP, &vvar_spec);
> + if (IS_ERR(vma))
> + return PTR_ERR(vma);
>
> /*
> * our vma flags don't have VM_WRITE so by default, the process isn't
> @@ -145,9 +153,12 @@ static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_int
> * It's fine to use that for setting breakpoints in the vDSO code
> * pages though.
> */
> - vma = _install_special_mapping(mm, vdso_base, vdso_size,
> + vma = _install_special_mapping(mm, vdso_base + vvar_size, vdso_size,
> VM_READ | VM_EXEC | VM_MAYREAD |
> VM_MAYWRITE | VM_MAYEXEC, vdso_spec);
> + if (IS_ERR(vma))
> + do_munmap(mm, vdso_base, vvar_size, NULL);
> +
> return PTR_ERR_OR_ZERO(vma);
> }
>
> @@ -249,11 +260,22 @@ static struct page ** __init vdso_setup_pages(void *start, void *end)
> if (!pagelist)
> panic("%s: Cannot allocate page list for VDSO", __func__);
>
> - pagelist[0] = virt_to_page(vdso_data);
> -
> for (i = 0; i < pages; i++)
> - pagelist[i + 1] = virt_to_page(start + i * PAGE_SIZE);
> + pagelist[i] = virt_to_page(start + i * PAGE_SIZE);
> +
> + return pagelist;
> +}
> +
> +static struct page ** __init vvar_setup_pages(void)
> +{
> + struct page **pagelist;
>
> + /* .pages is NULL-terminated */
> + pagelist = kcalloc(2, sizeof(struct page *), GFP_KERNEL);
> + if (!pagelist)
> + panic("%s: Cannot allocate page list for VVAR", __func__);
> +
> + pagelist[0] = virt_to_page(vdso_data);
> return pagelist;
> }
>
> @@ -295,6 +317,8 @@ static int __init vdso_init(void)
> if (IS_ENABLED(CONFIG_PPC64))
> vdso64_spec.pages = vdso_setup_pages(&vdso64_start, &vdso64_end);
>
> + vvar_spec.pages = vvar_setup_pages();
> +
> smp_wmb();
>
> return 0;
>
^ permalink raw reply
* Re: [PATCH] powerpc/64s: power4 nap fixup in C
From: Andreas Schwab @ 2021-03-29 15:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <87y2e6fu7v.fsf__9754.75274478725$1616992871$gmane$org@mpe.ellerman.id.au>
On Mär 29 2021, Michael Ellerman wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
>> There is no need for this to be in asm, use the new intrrupt entry wrapper.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> Hopefully this works on a real G5 now, but I couldn't reproduce the
>> problem with QEMU.
>
> It still prevents my G5 from booting.
I see differing failures. What's common is that there is a pause of
about 60 seconds before the crash occurs. It looks like the crash
occurs in power4_idle_nap+0x30/0x34. Unfortuately, the BootX console is
too small to see enough.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] PCI: Try to find two continuous regions for child resource
From: Bjorn Helgaas @ 2021-03-29 16:22 UTC (permalink / raw)
To: Kai-Heng Feng
Cc: Qian Cai, Michal Simek, Chen Zhou, Arnd Bergmann,
open list:SPARC + UltraSPARC (sparc/sparc64),
Alexey Kardashevskiy, open list:PCI SUBSYSTEM, open list,
Dominik Brodowski, Frederic Barrat, Qinglang Miao, Paul Mackerras,
Cédric Le Goater, bhelgaas, Oliver O'Halloran,
Andrew Morton, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
David S. Miller, Mike Rapoport
In-Reply-To: <20210329084804.257526-1-kai.heng.feng@canonical.com>
On Mon, Mar 29, 2021 at 04:47:59PM +0800, Kai-Heng Feng wrote:
> Built-in grahpics on HP EliteDesk 805 G6 doesn't work because graphics
> can't get the BAR it needs:
> [ 0.611504] pci_bus 0000:00: root bus resource [mem 0x10020200000-0x100303fffff window]
> [ 0.611505] pci_bus 0000:00: root bus resource [mem 0x10030400000-0x100401fffff window]
> ...
> [ 0.638083] pci 0000:00:08.1: bridge window [mem 0xd2000000-0xd23fffff]
> [ 0.638086] pci 0000:00:08.1: bridge window [mem 0x10030000000-0x100401fffff 64bit pref]
> [ 0.962086] pci 0000:00:08.1: can't claim BAR 15 [mem 0x10030000000-0x100401fffff 64bit pref]: no compatible bridge window
> [ 0.962086] pci 0000:00:08.1: [mem 0x10030000000-0x100401fffff 64bit pref] clipped to [mem 0x10030000000-0x100303fffff 64bit pref]
> [ 0.962086] pci 0000:00:08.1: bridge window [mem 0x10030000000-0x100303fffff 64bit pref]
> [ 0.962086] pci 0000:07:00.0: can't claim BAR 0 [mem 0x10030000000-0x1003fffffff 64bit pref]: no compatible bridge window
> [ 0.962086] pci 0000:07:00.0: can't claim BAR 2 [mem 0x10040000000-0x100401fffff 64bit pref]: no compatible bridge window
>
> However, the root bus has two continuous regions that can contain the
> child resource requested.
>
> So try to find another parent region if two regions are continuous and
> can contain child resource. This change makes the grahpics works on the
> system in question.
The BIOS description of PCI0 is interesting:
pci_bus 0000:00: root bus resource [mem 0x10000000000-0x100201fffff window]
pci_bus 0000:00: root bus resource [mem 0x10020200000-0x100303fffff window]
pci_bus 0000:00: root bus resource [mem 0x10030400000-0x100401fffff window]
So the PCI0 _CRS apparently gave us:
[mem 0x10000000000-0x100201fffff] size 0x20200000 (512MB + 2MB)
[mem 0x10020200000-0x100303fffff] size 0x10200000 (256MB + 2MB)
[mem 0x10030400000-0x100401fffff] size 0x0fe00000 (254MB)
These are all contiguous, so we'd have no problem if we coalesced them
into a single window:
[mem 0x10000000000-0x100401fffff window] size 0x40200000 (1GB + 2MB)
I think we currently keep these root bus resources separate because if
we ever support _SRS for host bridges, the argument we give to _SRS
must be exactly the same format as what we got from _CRS (see ACPI
v6.3, sec 6.2.16, and pnpacpi_set_resources()).
pnpacpi_encode_resources() is currently very simple-minded and copies
each device resource back into a single _SRS entry. But (1) we don't
support _SRS for host bridges, and (2) if we ever do, we can make
pnpacpi_encode_resources() smarter so it breaks things back up.
So I think we should try to fix this by coalescing these adjacent
resources from _CRS so we end up with a single root bus resource that
covers all contiguous regions.
Typos, etc:
- No need for the timestamps; they're not relevant to the problem.
- s/grahpics/graphics/ (two occurrences above)
- s/continuous/contiguous/ (three occurrences above)
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212013
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> arch/microblaze/pci/pci-common.c | 4 +--
> arch/powerpc/kernel/pci-common.c | 8 ++---
> arch/sparc/kernel/pci.c | 4 +--
> drivers/pci/pci.c | 60 +++++++++++++++++++++++++++-----
> drivers/pci/setup-res.c | 21 +++++++----
> drivers/pcmcia/rsrc_nonstatic.c | 4 +--
> include/linux/pci.h | 6 ++--
> 7 files changed, 80 insertions(+), 27 deletions(-)
>
> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
> index 557585f1be41..8e65832fb510 100644
> --- a/arch/microblaze/pci/pci-common.c
> +++ b/arch/microblaze/pci/pci-common.c
> @@ -669,7 +669,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
> {
> struct pci_bus *b;
> int i;
> - struct resource *res, *pr;
> + struct resource *res, *pr = NULL;
>
> pr_debug("PCI: Allocating bus resources for %04x:%02x...\n",
> pci_domain_nr(bus), bus->number);
> @@ -688,7 +688,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
> * and as such ensure proper re-allocation
> * later.
> */
> - pr = pci_find_parent_resource(bus->self, res);
> + pci_find_parent_resource(bus->self, res, &pr, NULL);
> if (pr == res) {
> /* this happens when the generic PCI
> * code (wrongly) decides that this
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index 001e90cd8948..f865354b746d 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -1196,7 +1196,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
> {
> struct pci_bus *b;
> int i;
> - struct resource *res, *pr;
> + struct resource *res, *pr = NULL;
>
> pr_debug("PCI: Allocating bus resources for %04x:%02x...\n",
> pci_domain_nr(bus), bus->number);
> @@ -1213,7 +1213,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
> pr = (res->flags & IORESOURCE_IO) ?
> &ioport_resource : &iomem_resource;
> else {
> - pr = pci_find_parent_resource(bus->self, res);
> + pci_find_parent_resource(bus->self, res, &pr, NULL);
> if (pr == res) {
> /* this happens when the generic PCI
> * code (wrongly) decides that this
> @@ -1265,12 +1265,12 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
>
> static inline void alloc_resource(struct pci_dev *dev, int idx)
> {
> - struct resource *pr, *r = &dev->resource[idx];
> + struct resource *pr = NULL, *r = &dev->resource[idx];
>
> pr_debug("PCI: Allocating %s: Resource %d: %pR\n",
> pci_name(dev), idx, r);
>
> - pr = pci_find_parent_resource(dev, r);
> + pci_find_parent_resource(dev, r, &pr, NULL);
> if (!pr || (pr->flags & IORESOURCE_UNSET) ||
> request_resource(pr, r) < 0) {
> printk(KERN_WARNING "PCI: Cannot allocate resource region %d"
> diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
> index 9c2b720bfd20..b4006798e4e1 100644
> --- a/arch/sparc/kernel/pci.c
> +++ b/arch/sparc/kernel/pci.c
> @@ -621,7 +621,7 @@ static void pci_bus_register_of_sysfs(struct pci_bus *bus)
> static void pci_claim_legacy_resources(struct pci_dev *dev)
> {
> struct pci_bus_region region;
> - struct resource *p, *root, *conflict;
> + struct resource *p, *root = NULL, *conflict;
>
> if ((dev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> return;
> @@ -637,7 +637,7 @@ static void pci_claim_legacy_resources(struct pci_dev *dev)
> region.end = region.start + 0x1ffffUL;
> pcibios_bus_to_resource(dev->bus, p, ®ion);
>
> - root = pci_find_parent_resource(dev, p);
> + pci_find_parent_resource(dev, p, &root, NULL);
> if (!root) {
> pci_info(dev, "can't claim VGA legacy %pR: no compatible bridge window\n", p);
> goto err;
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 16a17215f633..abbcd2dcdc02 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -693,20 +693,25 @@ u8 pci_find_ht_capability(struct pci_dev *dev, int ht_cap)
> EXPORT_SYMBOL_GPL(pci_find_ht_capability);
>
> /**
> - * pci_find_parent_resource - return resource region of parent bus of given
> + * pci_find_parent_resource - find resource region of parent bus of given
> * region
> * @dev: PCI device structure contains resources to be searched
> * @res: child resource record for which parent is sought
> + * @first: the first region that contains the child resource
> + * @second: the second region that combines with the first region to fully
> + * contains the child resource
> *
> * For given resource region of given device, return the resource region of
> * parent bus the given region is contained in.
> */
> -struct resource *pci_find_parent_resource(const struct pci_dev *dev,
> - struct resource *res)
> +void pci_find_parent_resource(const struct pci_dev *dev,
> + struct resource *res,
> + struct resource **first,
> + struct resource **second)
> {
> const struct pci_bus *bus = dev->bus;
> struct resource *r;
> - int i;
> + int i, overlaps = 0;
>
> pci_bus_for_each_resource(bus, r, i) {
> if (!r)
> @@ -718,8 +723,10 @@ struct resource *pci_find_parent_resource(const struct pci_dev *dev,
> * not, the allocator made a mistake.
> */
> if (r->flags & IORESOURCE_PREFETCH &&
> - !(res->flags & IORESOURCE_PREFETCH))
> - return NULL;
> + !(res->flags & IORESOURCE_PREFETCH)) {
> + *first = NULL;
> + return;
> + }
>
> /*
> * If we're below a transparent bridge, there may
> @@ -729,10 +736,47 @@ struct resource *pci_find_parent_resource(const struct pci_dev *dev,
> * on pci_bus_for_each_resource() giving us those
> * first.
> */
> - return r;
> + *first = r;
> + return;
> }
> }
> - return NULL;
> +
> + if (!second)
> + return;
> +
> + pci_bus_for_each_resource(bus, r, i) {
> + if (!r)
> + continue;
> + if (resource_overlaps(r, res)) {
> + if (r->flags & IORESOURCE_PREFETCH &&
> + !(res->flags & IORESOURCE_PREFETCH))
> + continue;
> +
> + if (!overlaps++)
> + *first = r;
> + else {
> + *second = r;
> + break;
> + }
> + }
> + }
> +
> + if (overlaps != 2)
> + goto out;
> +
> + if ((*first)->start > (*second)->start)
> + swap(*first, *second);
> +
> + if ((*first)->end + 1 != (*second)->start)
> + goto out;
> +
> + if ((*first)->start <= res->start && (*second)->end >= res->end)
> + return;
> +out:
> +
> + *first = NULL;
> + *second = NULL;
> + return;
> }
> EXPORT_SYMBOL(pci_find_parent_resource);
>
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index 7f1acb3918d0..e39615321d81 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -131,7 +131,7 @@ void pci_update_resource(struct pci_dev *dev, int resno)
> int pci_claim_resource(struct pci_dev *dev, int resource)
> {
> struct resource *res = &dev->resource[resource];
> - struct resource *root, *conflict;
> + struct resource *first = NULL, *second = NULL, *conflict;
>
> if (res->flags & IORESOURCE_UNSET) {
> pci_info(dev, "can't claim BAR %d %pR: no address assigned\n",
> @@ -147,21 +147,28 @@ int pci_claim_resource(struct pci_dev *dev, int resource)
> if (res->flags & IORESOURCE_ROM_SHADOW)
> return 0;
>
> - root = pci_find_parent_resource(dev, res);
> - if (!root) {
> + pci_find_parent_resource(dev, res, &first, &second);
> + if (!first) {
> pci_info(dev, "can't claim BAR %d %pR: no compatible bridge window\n",
> resource, res);
> res->flags |= IORESOURCE_UNSET;
> return -EINVAL;
> }
>
> - conflict = request_resource_conflict(root, res);
> + if (second)
> + first->end = second->end;
> +
> + conflict = request_resource_conflict(first, res);
> if (conflict) {
> + if (second)
> + first->end = second->start - 1;
> +
> pci_info(dev, "can't claim BAR %d %pR: address conflict with %s %pR\n",
> resource, res, conflict->name, conflict);
> res->flags |= IORESOURCE_UNSET;
> return -EBUSY;
> - }
> + } else if (second)
> + second->start = second->end = 0;
>
> return 0;
> }
> @@ -195,7 +202,7 @@ resource_size_t __weak pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx)
> static int pci_revert_fw_address(struct resource *res, struct pci_dev *dev,
> int resno, resource_size_t size)
> {
> - struct resource *root, *conflict;
> + struct resource *root = NULL, *conflict;
> resource_size_t fw_addr, start, end;
>
> fw_addr = pcibios_retrieve_fw_addr(dev, resno);
> @@ -208,7 +215,7 @@ static int pci_revert_fw_address(struct resource *res, struct pci_dev *dev,
> res->end = res->start + size - 1;
> res->flags &= ~IORESOURCE_UNSET;
>
> - root = pci_find_parent_resource(dev, res);
> + pci_find_parent_resource(dev, res, &root, NULL);
> if (!root) {
> if (res->flags & IORESOURCE_IO)
> root = &ioport_resource;
> diff --git a/drivers/pcmcia/rsrc_nonstatic.c b/drivers/pcmcia/rsrc_nonstatic.c
> index 3b05760e69d6..2fba42d7486e 100644
> --- a/drivers/pcmcia/rsrc_nonstatic.c
> +++ b/drivers/pcmcia/rsrc_nonstatic.c
> @@ -73,7 +73,7 @@ static struct resource *
> claim_region(struct pcmcia_socket *s, resource_size_t base,
> resource_size_t size, int type, char *name)
> {
> - struct resource *res, *parent;
> + struct resource *res, *parent = NULL;
>
> parent = type & IORESOURCE_MEM ? &iomem_resource : &ioport_resource;
> res = pcmcia_make_resource(base, size, type | IORESOURCE_BUSY, name);
> @@ -81,7 +81,7 @@ claim_region(struct pcmcia_socket *s, resource_size_t base,
> if (res) {
> #ifdef CONFIG_PCI
> if (s && s->cb_dev)
> - parent = pci_find_parent_resource(s->cb_dev, res);
> + pci_find_parent_resource(s->cb_dev, res, &parent, NULL);
> #endif
> if (!parent || request_resource(parent, res)) {
> kfree(res);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 86c799c97b77..dd1455be5247 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1049,8 +1049,10 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus);
> unsigned int pci_scan_child_bus(struct pci_bus *bus);
> void pci_bus_add_device(struct pci_dev *dev);
> void pci_read_bridge_bases(struct pci_bus *child);
> -struct resource *pci_find_parent_resource(const struct pci_dev *dev,
> - struct resource *res);
> +void pci_find_parent_resource(const struct pci_dev *dev,
> + struct resource *res,
> + struct resource **first,
> + struct resource **second);
> u8 pci_swizzle_interrupt_pin(const struct pci_dev *dev, u8 pin);
> int pci_get_interrupt_pin(struct pci_dev *dev, struct pci_dev **bridge);
> u8 pci_common_swizzle(struct pci_dev *dev, u8 *pinp);
> --
> 2.30.2
>
^ permalink raw reply
* Re: [PATCH] powerpc/64s: power4 nap fixup in C
From: Andreas Schwab @ 2021-03-29 16:23 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <87v99aj7tr.fsf__47134.2879392736$1617031867$gmane$org@igel.home>
On Mär 29 2021, Andreas Schwab wrote:
> On Mär 29 2021, Michael Ellerman wrote:
>
>> Nicholas Piggin <npiggin@gmail.com> writes:
>>> There is no need for this to be in asm, use the new intrrupt entry wrapper.
>>>
>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
>>> Hopefully this works on a real G5 now, but I couldn't reproduce the
>>> problem with QEMU.
>>
>> It still prevents my G5 from booting.
>
> I see differing failures. What's common is that there is a pause of
> about 60 seconds before the crash occurs. It looks like the crash
> occurs in power4_idle_nap+0x30/0x34. Unfortuately, the BootX console is
> too small to see enough.
I was now able to see the messages on the VGA console, and the problem
is actually that the cpus are starting to stall.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] powerpc/64s: power4 nap fixup in C
From: Andreas Schwab @ 2021-03-29 16:51 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <87czvikwb7.fsf__13924.9042653077$1617019017$gmane$org@igel.home>
On Mär 29 2021, Andreas Schwab wrote:
> On Mär 29 2021, Christophe Leroy wrote:
>
>> Le 29/03/2021 à 10:33, Benjamin Herrenschmidt a écrit :
>>> On Fri, 2021-03-12 at 11:20 +1000, Nicholas Piggin wrote:
>>>>
>>>> +static inline void nap_adjust_return(struct pt_regs *regs)
>>>>
>>>> +{
>>>>
>>>> +#ifdef CONFIG_PPC_970_NAP
>>>>
>>>> + if (unlikely(test_thread_local_flags(_TLF_NAPPING))) {
>>>> + /* Can avoid a test-and-clear because NMIs do not call this */
>>>> + clear_thread_local_flags(_TLF_NAPPING);
>>>> + regs->nip = (unsigned long)power4_idle_nap_return;
>>>> + }
>>> Is this a pointer to a function descriptor or the actual code ?
>>>
>>
>> --- a/arch/powerpc/kernel/idle_book3s.S
>> +++ b/arch/powerpc/kernel/idle_book3s.S
>> @@ -209,4 +209,8 @@ _GLOBAL(power4_idle_nap)
>> mtmsrd r7
>> isync
>> b 1b
>> +
>> + .globl power4_idle_nap_return
>> +power4_idle_nap_return:
>> + blr
>> #endif
>
> The problem is not the definition, it is the reference. In C, a
> function symbol always resolves to the address of the descriptor.
Sorry, this is wrong, I have misremembered how function descriptors work
on ppc64. The address is really pointing to the actual code.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* [PATCH v3] powerpc/papr_scm: Implement support for H_SCM_FLUSH hcall
From: Shivaprasad G Bhat @ 2021-03-29 17:36 UTC (permalink / raw)
To: sbhat, linuxppc-dev, kvm-ppc, linux-nvdimm, aneesh.kumar,
ellerman
Cc: vaibhav, linux-doc
Add support for ND_REGION_ASYNC capability if the device tree
indicates 'ibm,hcall-flush-required' property in the NVDIMM node.
Flush is done by issuing H_SCM_FLUSH hcall to the hypervisor.
If the flush request failed, the hypervisor is expected to
to reflect the problem in the subsequent nvdimm H_SCM_HEALTH call.
This patch prevents mmap of namespaces with MAP_SYNC flag if the
nvdimm requires an explicit flush[1].
References:
[1] https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/memory/ndctl.py.data/map_sync.c
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
---
v2 - https://www.spinics.net/lists/kvm-ppc/msg18799.html
Changes from v2:
- Fixed the commit message.
- Add dev_dbg before the H_SCM_FLUSH hcall
v1 - https://www.spinics.net/lists/kvm-ppc/msg18272.html
Changes from v1:
- Hcall semantics finalized, all changes are to accomodate them.
Documentation/powerpc/papr_hcalls.rst | 14 ++++++++++
arch/powerpc/include/asm/hvcall.h | 3 +-
arch/powerpc/platforms/pseries/papr_scm.c | 40 +++++++++++++++++++++++++++++
3 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/Documentation/powerpc/papr_hcalls.rst b/Documentation/powerpc/papr_hcalls.rst
index 48fcf1255a33..648f278eea8f 100644
--- a/Documentation/powerpc/papr_hcalls.rst
+++ b/Documentation/powerpc/papr_hcalls.rst
@@ -275,6 +275,20 @@ Health Bitmap Flags:
Given a DRC Index collect the performance statistics for NVDIMM and copy them
to the resultBuffer.
+**H_SCM_FLUSH**
+
+| Input: *drcIndex, continue-token*
+| Out: *continue-token*
+| Return Value: *H_SUCCESS, H_Parameter, H_P2, H_BUSY*
+
+Given a DRC Index Flush the data to backend NVDIMM device.
+
+The hcall returns H_BUSY when the flush takes longer time and the hcall needs
+to be issued multiple times in order to be completely serviced. The
+*continue-token* from the output to be passed in the argument list of
+subsequent hcalls to the hypervisor until the hcall is completely serviced
+at which point H_SUCCESS or other error is returned by the hypervisor.
+
References
==========
.. [1] "Power Architecture Platform Reference"
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index ed6086d57b22..9f7729a97ebd 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -315,7 +315,8 @@
#define H_SCM_HEALTH 0x400
#define H_SCM_PERFORMANCE_STATS 0x418
#define H_RPT_INVALIDATE 0x448
-#define MAX_HCALL_OPCODE H_RPT_INVALIDATE
+#define H_SCM_FLUSH 0x44C
+#define MAX_HCALL_OPCODE H_SCM_FLUSH
/* Scope args for H_SCM_UNBIND_ALL */
#define H_UNBIND_SCOPE_ALL (0x1)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index 835163f54244..b7a47fcc5aa5 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -93,6 +93,7 @@ struct papr_scm_priv {
uint64_t block_size;
int metadata_size;
bool is_volatile;
+ bool hcall_flush_required;
uint64_t bound_addr;
@@ -117,6 +118,39 @@ struct papr_scm_priv {
size_t stat_buffer_len;
};
+static int papr_scm_pmem_flush(struct nd_region *nd_region,
+ struct bio *bio __maybe_unused)
+{
+ struct papr_scm_priv *p = nd_region_provider_data(nd_region);
+ unsigned long ret_buf[PLPAR_HCALL_BUFSIZE];
+ uint64_t token = 0;
+ int64_t rc;
+
+ dev_dbg(&p->pdev->dev, "flush drc 0x%x", p->drc_index);
+
+ do {
+ rc = plpar_hcall(H_SCM_FLUSH, ret_buf, p->drc_index, token);
+ token = ret_buf[0];
+
+ /* Check if we are stalled for some time */
+ if (H_IS_LONG_BUSY(rc)) {
+ msleep(get_longbusy_msecs(rc));
+ rc = H_BUSY;
+ } else if (rc == H_BUSY) {
+ cond_resched();
+ }
+ } while (rc == H_BUSY);
+
+ if (rc) {
+ dev_err(&p->pdev->dev, "flush error: %lld", rc);
+ rc = -EIO;
+ } else {
+ dev_dbg(&p->pdev->dev, "flush drc 0x%x complete", p->drc_index);
+ }
+
+ return rc;
+}
+
static LIST_HEAD(papr_nd_regions);
static DEFINE_MUTEX(papr_ndr_lock);
@@ -943,6 +977,11 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
ndr_desc.num_mappings = 1;
ndr_desc.nd_set = &p->nd_set;
+ if (p->hcall_flush_required) {
+ set_bit(ND_REGION_ASYNC, &ndr_desc.flags);
+ ndr_desc.flush = papr_scm_pmem_flush;
+ }
+
if (p->is_volatile)
p->region = nvdimm_volatile_region_create(p->bus, &ndr_desc);
else {
@@ -1088,6 +1127,7 @@ static int papr_scm_probe(struct platform_device *pdev)
p->block_size = block_size;
p->blocks = blocks;
p->is_volatile = !of_property_read_bool(dn, "ibm,cache-flush-required");
+ p->hcall_flush_required = of_property_read_bool(dn, "ibm,hcall-flush-required");
/* We just need to ensure that set cookies are unique across */
uuid_parse(uuid_str, (uuid_t *) uuid);
^ permalink raw reply related
* Re: [PATCH] ASoC: fsl_rpmsg: initialise pointers to NULL
From: Mark Brown @ 2021-03-29 19:58 UTC (permalink / raw)
To: alsa-devel, timur, Xiubo.Lee, linux-kernel, festevam,
nicoleotsuka, tiwai, perex, linuxppc-dev, Shengjiu Wang,
lgirdwood
Cc: Mark Brown
In-Reply-To: <1616988868-971-1-git-send-email-shengjiu.wang@nxp.com>
On Mon, 29 Mar 2021 11:34:28 +0800, Shengjiu Wang wrote:
> This fixes the following sparse warnings:
>
> sound/soc/fsl/fsl_rpmsg.c:45:45: sparse: sparse: Using plain integer as NULL pointer
> sound/soc/fsl/fsl_rpmsg.c:45:56: sparse: sparse: Using plain integer as NULL pointer
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl_rpmsg: initialise pointers to NULL
commit: 502e5321d89214a34a7b8bda697fc98d14b51cae
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
^ permalink raw reply
* Re: [PATCH] powerpc/vdso: Separate vvar vma from vdso
From: Dmitry Safonov @ 2021-03-29 19:59 UTC (permalink / raw)
To: Laurent Dufour, linux-kernel
Cc: Dmitry Safonov, Andrei Vagin, Paul Mackerras, stable,
Andy Lutomirski, linuxppc-dev
In-Reply-To: <f97f3ff9-6ae2-64cc-fada-49fcac34ae47@linux.ibm.com>
On 3/29/21 4:14 PM, Laurent Dufour wrote:
> Le 26/03/2021 à 20:17, Dmitry Safonov a écrit :
>> Since commit 511157ab641e ("powerpc/vdso: Move vdso datapage up front")
>> VVAR page is in front of the VDSO area. In result it breaks CRIU
>> (Checkpoint Restore In Userspace) [1], where CRIU expects that "[vdso]"
>> from /proc/../maps points at ELF/vdso image, rather than at VVAR data
>> page.
>> Laurent made a patch to keep CRIU working (by reading aux vector).
>> But I think it still makes sence to separate two mappings into different
>> VMAs. It will also make ppc64 less "special" for userspace and as
>> a side-bonus will make VVAR page un-writable by debugger (which
>> previously
>> would COW page and can be unexpected).
>>
>> I opportunistically Cc stable on it: I understand that usually such
>> stuff isn't a stable material, but that will allow us in CRIU have
>> one workaround less that is needed just for one release (v5.11) on
>> one platform (ppc64), which we otherwise have to maintain.
>> I wouldn't go as far as to say that the commit 511157ab641e is ABI
>> regression as no other userspace got broken, but I'd really appreciate
>> if it gets backported to v5.11 after v5.12 is released, so as not
>> to complicate already non-simple CRIU-vdso code. Thanks!
>>
>> Cc: Andrei Vagin <avagin@gmail.com>
>> Cc: Andy Lutomirski <luto@kernel.org>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
>> Cc: Laurent Dufour <ldufour@linux.ibm.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: stable@vger.kernel.org # v5.11
>> [1]: https://github.com/checkpoint-restore/criu/issues/1417
>> Signed-off-by: Dmitry Safonov <dima@arista.com>
>> Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>
> I run the CRIU's test suite and except the usual suspects, all the tests
> passed.
>
> Tested-by: Laurent Dufour <ldufour@linux.ibm.com>
Thank you, Laurent!
--
Dmitry
^ permalink raw reply
* Re: [PATCH v11 0/6] KASAN for powerpc64 radix
From: Michael Ellerman @ 2021-03-29 23:53 UTC (permalink / raw)
To: Christophe Leroy, Daniel Axtens, linux-kernel, linux-mm,
linuxppc-dev, kasan-dev, aneesh.kumar, bsingharora
In-Reply-To: <a5e1d7c5-3ebc-283c-2c9d-55d36d03cf48@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 23/03/2021 à 02:21, Daniel Axtens a écrit :
>> Hi Christophe,
>>
>>> In the discussion we had long time ago,
>>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20190806233827.16454-5-dja@axtens.net/#2321067
>>> , I challenged you on why it was not possible to implement things the same way as other
>>> architectures, in extenso with an early mapping.
>>>
>>> Your first answer was that too many things were done in real mode at startup. After some discussion
>>> you said that finally there was not that much things at startup but the issue was KVM.
>>>
>>> Now you say that instrumentation on KVM is fully disabled.
>>>
>>> So my question is, if KVM is not a problem anymore, why not go the standard way with an early shadow
>>> ? Then you could also support inline instrumentation.
>>
>> Fair enough, I've had some trouble both understanding the problem myself
>> and clearly articulating it. Let me try again.
>>
>> We need translations on to access the shadow area.
>>
>> We reach setup_64.c::early_setup() with translations off. At this point
>> we don't know what MMU we're running under, or our CPU features.
>
> What do you need to know ? Whether it is Hash or Radix, or
> more/different details ?
Yes, as well as some other details like SLB size, supported segment &
page sizes, possibly the CPU version for workarounds, various other
device tree things.
You also need to know if you're bare metal or in a guest, or on a PS3 ...
> IIUC, today we only support KASAN on Radix. Would it make sense to say that a kernel built with
> KASAN can only run on processors having Radix capacility ? Then select CONFIG_PPC_RADIX_MMU_DEFAULT
> when KASAN is set, and accept that the kernel crashes if Radix is not available ?
I would rather not. We already have some options like that
(EARLY_DEBUG), and they have caused people to waste time debugging
crashes over the years that turned out to just due to the wrong CONFIG
selected.
>> To determine our MMU and CPU features, early_setup() calls functions
>> (dt_cpu_ftrs_init, early_init_devtree) that call out to generic code
>> like of_scan_flat_dt. We need to do this before we turn on translations
>> because we can't set up the MMU until we know what MMU we have.
>>
>> So this puts us in a bind:
>>
>> - We can't set up an early shadow until we have translations on, which
>> requires that the MMU is set up.
>>
>> - We can't set up an MMU until we call out to generic code for FDT
>> parsing.
>>
>> So there will be calls to generic FDT parsing code that happen before the
>> early shadow is set up.
>
> I see some logic in kernel/prom_init.c for detecting MMU. Can we get the information from there in
> order to setup the MMU ?
You could find some of the information, but you'd need to stash it
somewhere (like the flat device tree :P) because you can't turn the MMU
on until we shutdown open firmware.
That also doesn't help you on bare metal where we don't use prom_init.
>> The setup code also prints a bunch of information about the platform
>> with printk() while translations are off, so it wouldn't even be enough
>> to disable instrumentation for bits of the generic DT code on ppc64.
>
> I'm sure the printk() stuff can be avoided or delayed without much problems, I guess the main
> problem is the DT code, isn't it ?
We spent many years making printk() work for early boot messages,
because it has the nice property of being persisted in dmesg.
But possibly we could come up with some workaround for that.
Disabling KASAN for the flat DT code seems like it wouldn't be a huge
loss, most (all?) of that code should only run at boot anyway.
But we also have code spread out in various files that would need to be
built without KASAN. See eg. everything called by of_scan_flat_dt(),
mmu_early_init_devtree(), pseries_probe_fw_features()
pkey_early_init_devtree() etc.
Because we can only disable KASAN per-file that would require quite a
bit of code movement and related churn.
> As far as I can see the code only use udbg_printf() before MMU is on, and this could be simply
> skipped when KASAN is selected, I see no situation where you need early printk together with KASAN.
We definitely use printk() before the MMU is on.
>> Does that make sense? If you can figure out how to 'square the circle'
>> here I'm all ears.
>
> Yes it is a lot more clear now, thanks you. Gave a few ideas above,
> does it help ?
A little? :)
It's possible we could do slightly less of the current boot sequence
before turning the MMU on. But we would still need to scan the flat
device tree, so all that code would be implicated either way.
We could also rearrange the early boot code to put bits in separate
files so they can be built without KASAN, but like I said above that
would be a lot of churn.
I don't see a way to fix printk() though, other than not using it during
early boot. Maybe that's OK but it feels like a bit of a backward step.
There's also other issues, like if we WARN during early boot that causes
a program check and that runs all sorts of code, some of which would
have KASAN enabled.
So I don't see an easy path to enabling inline instrumentation. It's
obviously possible, but I don't think it's something we can get done in
any reasonable time frame.
cheers
^ permalink raw reply
* Re: [PATCH v3 11/17] riscv: Convert to GENERIC_CMDLINE
From: Nick Kossifidis @ 2021-03-30 0:52 UTC (permalink / raw)
To: Rob Herring
Cc: open list:GENERIC INCLUDE/ASM HEADER FILES, devicetree,
microblaze, Daniel Gimpelevich, linux-xtensa, SH-Linux,
linuxppc-dev, X86 ML, linux-kernel, open list:MIPS, Openrisc,
Andreas Schwab, nios2, paul.walmsley, linux-hexagon, sparclinux,
linux-riscv, Will Deacon, linux-arm-kernel, Daniel Walker
In-Reply-To: <CAL_JsqK2TT=j1QjiRgTYQvwHqivE-3HgYo2JzxTJSWO2wvK69Q@mail.gmail.com>
Στις 2021-03-26 17:26, Rob Herring έγραψε:
> On Fri, Mar 26, 2021 at 8:20 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>>
>>
>> Le 26/03/2021 à 15:08, Andreas Schwab a écrit :
>> > On Mär 26 2021, Christophe Leroy wrote:
>> >
>> >> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
>> >> index f8f15332caa2..e7c91ee478d1 100644
>> >> --- a/arch/riscv/kernel/setup.c
>> >> +++ b/arch/riscv/kernel/setup.c
>> >> @@ -20,6 +20,7 @@
>> >> #include <linux/swiotlb.h>
>> >> #include <linux/smp.h>
>> >> #include <linux/efi.h>
>> >> +#include <linux/cmdline.h>
>> >>
>> >> #include <asm/cpu_ops.h>
>> >> #include <asm/early_ioremap.h>
>> >> @@ -228,10 +229,8 @@ static void __init parse_dtb(void)
>> >> }
>> >>
>> >> pr_err("No DTB passed to the kernel\n");
>> >> -#ifdef CONFIG_CMDLINE_FORCE
>> >> - strlcpy(boot_command_line, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
>> >> + cmdline_build(boot_command_line, NULL, COMMAND_LINE_SIZE);
>> >> pr_info("Forcing kernel command line to: %s\n", boot_command_line);
>> >
>> > Shouldn't that message become conditional in some way?
>> >
>>
>> You are right, I did something similar on ARM but looks like I missed
>> it on RISCV.
>
> How is this hunk even useful? Under what conditions can you boot
> without a DTB? Even with a built-in DTB, the DT cmdline handling would
> be called.
>
> Rob
>
cced Paul who introduced this:
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/arch/riscv/kernel/setup.c?id=8fd6e05c7463b635e51ec7df0a1858c1b5a6e350
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 53f1d31708f6240e4615b0927df31f182e389e2f
From: kernel test robot @ 2021-03-30 1:54 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 53f1d31708f6240e4615b0927df31f182e389e2f powerpc/mm/book3s64: Use the correct storage key value when calling H_PROTECT
elapsed time: 3677m
configs tested: 297
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
sh sh7763rdp_defconfig
arm lpc32xx_defconfig
arm64 alldefconfig
xtensa defconfig
powerpc mpc837x_rdb_defconfig
m68k atari_defconfig
sh se7712_defconfig
arc nsim_700_defconfig
arc tb10x_defconfig
arm keystone_defconfig
powerpc pcm030_defconfig
powerpc socrates_defconfig
mips lemote2f_defconfig
powerpc ppc44x_defconfig
arm vt8500_v6_v7_defconfig
arm cm_x300_defconfig
riscv alldefconfig
arm hisi_defconfig
microblaze mmu_defconfig
powerpc mpc834x_itxgp_defconfig
arc hsdk_defconfig
sh hp6xx_defconfig
powerpc makalu_defconfig
powerpc walnut_defconfig
parisc generic-32bit_defconfig
sh ecovec24_defconfig
arc vdk_hs38_smp_defconfig
arm versatile_defconfig
arm mv78xx0_defconfig
powerpc akebono_defconfig
powerpc adder875_defconfig
sh microdev_defconfig
arm multi_v7_defconfig
sh defconfig
arm pxa255-idp_defconfig
arm iop32x_defconfig
powerpc mpc836x_mds_defconfig
nios2 10m50_defconfig
openrisc defconfig
powerpc holly_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm orion5x_defconfig
powerpc chrp32_defconfig
arm omap2plus_defconfig
sh rsk7264_defconfig
riscv nommu_virt_defconfig
um kunit_defconfig
powerpc sam440ep_defconfig
powerpc storcenter_defconfig
parisc allyesconfig
arm simpad_defconfig
m68k stmark2_defconfig
nds32 alldefconfig
arc haps_hs_smp_defconfig
arm footbridge_defconfig
ia64 zx1_defconfig
m68k defconfig
arm imote2_defconfig
xtensa generic_kc705_defconfig
powerpc mpc8540_ads_defconfig
m68k mvme16x_defconfig
mips maltaup_xpa_defconfig
powerpc ppc40x_defconfig
sh rts7751r2dplus_defconfig
h8300 h8s-sim_defconfig
m68k apollo_defconfig
mips omega2p_defconfig
um i386_defconfig
powerpc sbc8548_defconfig
powerpc mpc866_ads_defconfig
powerpc ebony_defconfig
sh titan_defconfig
sparc64 defconfig
mips tb0219_defconfig
mips ar7_defconfig
arm am200epdkit_defconfig
arm pxa910_defconfig
arm collie_defconfig
powerpc mpc834x_itx_defconfig
sh se7722_defconfig
parisc generic-64bit_defconfig
m68k mvme147_defconfig
h8300 h8300h-sim_defconfig
m68k m5475evb_defconfig
sparc allyesconfig
sh ecovec24-romimage_defconfig
arm vexpress_defconfig
powerpc bluestone_defconfig
powerpc acadia_defconfig
arm multi_v4t_defconfig
arm mps2_defconfig
powerpc cell_defconfig
powerpc motionpro_defconfig
mips gcw0_defconfig
arm gemini_defconfig
powerpc ppa8548_defconfig
mips cobalt_defconfig
powerpc mpc885_ads_defconfig
arm aspeed_g4_defconfig
riscv nommu_k210_defconfig
arm cns3420vb_defconfig
sh sh2007_defconfig
arm tct_hammer_defconfig
m68k mac_defconfig
powerpc64 alldefconfig
sh se7705_defconfig
powerpc rainier_defconfig
powerpc g5_defconfig
powerpc tqm8541_defconfig
i386 alldefconfig
sparc sparc64_defconfig
arm colibri_pxa300_defconfig
powerpc mpc85xx_cds_defconfig
sh rsk7203_defconfig
powerpc redwood_defconfig
powerpc tqm5200_defconfig
arm colibri_pxa270_defconfig
sh edosk7705_defconfig
sh se7724_defconfig
m68k m5407c3_defconfig
arm pcm027_defconfig
mips rs90_defconfig
sh dreamcast_defconfig
arm eseries_pxa_defconfig
mips rb532_defconfig
arm clps711x_defconfig
powerpc mpc837x_mds_defconfig
arm mini2440_defconfig
arm tegra_defconfig
mips pistachio_defconfig
openrisc simple_smp_defconfig
mips nlm_xlp_defconfig
arm pxa3xx_defconfig
powerpc mpc8272_ads_defconfig
sh kfr2r09_defconfig
arm neponset_defconfig
powerpc mpc8313_rdb_defconfig
sh sdk7780_defconfig
powerpc mpc8560_ads_defconfig
sh r7785rp_defconfig
m68k bvme6000_defconfig
arm pxa_defconfig
sh ap325rxa_defconfig
mips maltaup_defconfig
powerpc katmai_defconfig
powerpc mpc5200_defconfig
mips loongson1b_defconfig
mips decstation_defconfig
sh apsh4a3a_defconfig
arm assabet_defconfig
sh alldefconfig
arm s3c6400_defconfig
xtensa common_defconfig
powerpc mpc834x_mds_defconfig
powerpc bamboo_defconfig
powerpc warp_defconfig
powerpc mpc8315_rdb_defconfig
powerpc pq2fads_defconfig
m68k q40_defconfig
arm h5000_defconfig
sh edosk7760_defconfig
sh sh7757lcr_defconfig
powerpc ps3_defconfig
arm mainstone_defconfig
arm omap1_defconfig
sparc64 alldefconfig
riscv nommu_k210_sdcard_defconfig
arm shannon_defconfig
powerpc ppc6xx_defconfig
arm ixp4xx_defconfig
arc axs103_smp_defconfig
arm spitz_defconfig
arm s3c2410_defconfig
arm jornada720_defconfig
mips pic32mzda_defconfig
mips jmr3927_defconfig
m68k m5275evb_defconfig
sh se7206_defconfig
mips cu1830-neo_defconfig
sh shmin_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
s390 defconfig
sparc defconfig
i386 defconfig
i386 tinyconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a002-20210329
x86_64 randconfig-a003-20210329
x86_64 randconfig-a006-20210329
x86_64 randconfig-a001-20210329
x86_64 randconfig-a005-20210329
x86_64 randconfig-a004-20210329
i386 randconfig-a003-20210329
i386 randconfig-a004-20210329
i386 randconfig-a001-20210329
i386 randconfig-a002-20210329
i386 randconfig-a006-20210329
i386 randconfig-a005-20210329
i386 randconfig-a003-20210327
i386 randconfig-a004-20210327
i386 randconfig-a001-20210327
i386 randconfig-a002-20210327
i386 randconfig-a006-20210327
i386 randconfig-a005-20210327
x86_64 randconfig-a015-20210328
x86_64 randconfig-a012-20210328
x86_64 randconfig-a013-20210328
x86_64 randconfig-a014-20210328
x86_64 randconfig-a016-20210328
x86_64 randconfig-a011-20210328
i386 randconfig-a011-20210329
i386 randconfig-a016-20210329
i386 randconfig-a013-20210329
i386 randconfig-a012-20210329
i386 randconfig-a014-20210329
i386 randconfig-a015-20210329
i386 randconfig-a014-20210326
i386 randconfig-a011-20210326
i386 randconfig-a015-20210326
i386 randconfig-a016-20210326
i386 randconfig-a012-20210326
i386 randconfig-a013-20210326
i386 randconfig-a014-20210327
i386 randconfig-a011-20210327
i386 randconfig-a015-20210327
i386 randconfig-a016-20210327
i386 randconfig-a012-20210327
i386 randconfig-a013-20210327
x86_64 randconfig-a002-20210327
x86_64 randconfig-a003-20210327
x86_64 randconfig-a006-20210327
x86_64 randconfig-a001-20210327
x86_64 randconfig-a004-20210327
x86_64 randconfig-a005-20210327
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a002-20210328
x86_64 randconfig-a003-20210328
x86_64 randconfig-a001-20210328
x86_64 randconfig-a006-20210328
x86_64 randconfig-a005-20210328
x86_64 randconfig-a004-20210328
x86_64 randconfig-a015-20210329
x86_64 randconfig-a012-20210329
x86_64 randconfig-a013-20210329
x86_64 randconfig-a014-20210329
x86_64 randconfig-a011-20210329
x86_64 randconfig-a016-20210329
x86_64 randconfig-a012-20210327
x86_64 randconfig-a015-20210327
x86_64 randconfig-a014-20210327
x86_64 randconfig-a013-20210327
x86_64 randconfig-a011-20210327
x86_64 randconfig-a016-20210327
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] scsi: ibmvscsi: delete the useless casting value returned
From: Martin K. Petersen @ 2021-03-30 3:54 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, James E.J. Bottomley, Wang Qing,
linux-kernel, Tyrel Datwyler, linux-scsi, Paul Mackerras,
Benjamin Herrenschmidt
Cc: Martin K . Petersen
In-Reply-To: <1615515534-1250-1-git-send-email-wangqing@vivo.com>
On Fri, 12 Mar 2021 10:18:53 +0800, Wang Qing wrote:
> Fix the following coccicheck warning:
> WARNING: casting value returned by memory allocation function is useless.
Applied to 5.13/scsi-queue, thanks!
[1/1] scsi: ibmvscsi: delete the useless casting value returned
https://git.kernel.org/mkp/scsi/c/0d556a21a9da
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* [PATCH v10 00/10] powerpc: Further Strict RWX support
From: Jordan Niethe @ 2021-03-30 4:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ajd, cmr, npiggin, Jordan Niethe, naveen.n.rao, dja
Another revision to this series adding more Strict RWX support on powerpc, in
particular Strict Module RWX. This revision adds consideration for bpf.
The changes in v10 for each patch:
Christophe Leroy (2):
powerpc/mm: implement set_memory_attr()
powerpc/32: use set_memory_attr()
Jordan Niethe (3):
powerpc/lib/code-patching: Set up Strict RWX patching earlier
powerpc: Always define MODULES_{VADDR,END}
v10: - New to series
powerpc/bpf: Write protect JIT code
v10: - New to series
Russell Currey (5):
powerpc/mm: Implement set_memory() routines
v10: - WARN if trying to change the hash linear map
powerpc/kprobes: Mark newly allocated probes as ROX
v10: - Use __vmalloc_node_range()
powerpc/mm/ptdump: debugfs handler for W+X checks at runtime
v10: check_wx_pages now affects kernel_page_tables rather
then triggers its own action.
powerpc: Set ARCH_HAS_STRICT_MODULE_RWX
v10: - Predicate on !PPC_BOOK3S_604
- Make module_alloc() use PAGE_KERNEL protection
powerpc/configs: Enable STRICT_MODULE_RWX in skiroot_defconfig
arch/powerpc/Kconfig | 2 +
arch/powerpc/Kconfig.debug | 6 +-
arch/powerpc/configs/skiroot_defconfig | 1 +
arch/powerpc/include/asm/pgtable.h | 5 +
arch/powerpc/include/asm/set_memory.h | 34 +++++++
arch/powerpc/kernel/kprobes.c | 14 +++
arch/powerpc/kernel/module.c | 14 +--
arch/powerpc/lib/code-patching.c | 12 +--
arch/powerpc/mm/Makefile | 2 +-
arch/powerpc/mm/pageattr.c | 121 +++++++++++++++++++++++++
arch/powerpc/mm/pgtable_32.c | 60 ++----------
arch/powerpc/mm/ptdump/ptdump.c | 34 ++++++-
arch/powerpc/net/bpf_jit_comp.c | 5 +-
arch/powerpc/net/bpf_jit_comp64.c | 4 +
14 files changed, 245 insertions(+), 69 deletions(-)
create mode 100644 arch/powerpc/include/asm/set_memory.h
create mode 100644 arch/powerpc/mm/pageattr.c
--
2.25.1
^ permalink raw reply
* [PATCH v10 01/10] powerpc/mm: Implement set_memory() routines
From: Jordan Niethe @ 2021-03-30 4:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ajd, cmr, npiggin, naveen.n.rao, Jordan Niethe, dja
In-Reply-To: <20210330045132.722243-1-jniethe5@gmail.com>
From: Russell Currey <ruscur@russell.cc>
The set_memory_{ro/rw/nx/x}() functions are required for STRICT_MODULE_RWX,
and are generally useful primitives to have. This implementation is
designed to be completely generic across powerpc's many MMUs.
It's possible that this could be optimised to be faster for specific
MMUs, but the focus is on having a generic and safe implementation for
now.
This implementation does not handle cases where the caller is attempting
to change the mapping of the page it is executing from, or if another
CPU is concurrently using the page being altered. These cases likely
shouldn't happen, but a more complex implementation with MMU-specific code
could safely handle them, so that is left as a TODO for now.
On hash the linear mapping is not kept in the linux pagetable, so this
will not change the protection if used on that range. Currently these
functions are not used on the linear map so just WARN for now.
These functions do nothing if STRICT_KERNEL_RWX is not enabled.
Reviewed-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
[jpn: -rebase on next plus "powerpc/mm/64s: Allow STRICT_KERNEL_RWX again"
- WARN on hash linear map]
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
v10: WARN if trying to change the hash linear map
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/set_memory.h | 32 ++++++++++
arch/powerpc/mm/Makefile | 2 +-
arch/powerpc/mm/pageattr.c | 88 +++++++++++++++++++++++++++
4 files changed, 122 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/include/asm/set_memory.h
create mode 100644 arch/powerpc/mm/pageattr.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fc7f5c5933e6..4498a27ac9db 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -135,6 +135,7 @@ config PPC
select ARCH_HAS_MEMBARRIER_CALLBACKS
select ARCH_HAS_MEMBARRIER_SYNC_CORE
select ARCH_HAS_SCALED_CPUTIME if VIRT_CPU_ACCOUNTING_NATIVE && PPC_BOOK3S_64
+ select ARCH_HAS_SET_MEMORY
select ARCH_HAS_STRICT_KERNEL_RWX if ((PPC_BOOK3S_64 || PPC32) && !HIBERNATION)
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UACCESS_FLUSHCACHE
diff --git a/arch/powerpc/include/asm/set_memory.h b/arch/powerpc/include/asm/set_memory.h
new file mode 100644
index 000000000000..64011ea444b4
--- /dev/null
+++ b/arch/powerpc/include/asm/set_memory.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_POWERPC_SET_MEMORY_H
+#define _ASM_POWERPC_SET_MEMORY_H
+
+#define SET_MEMORY_RO 0
+#define SET_MEMORY_RW 1
+#define SET_MEMORY_NX 2
+#define SET_MEMORY_X 3
+
+int change_memory_attr(unsigned long addr, int numpages, long action);
+
+static inline int set_memory_ro(unsigned long addr, int numpages)
+{
+ return change_memory_attr(addr, numpages, SET_MEMORY_RO);
+}
+
+static inline int set_memory_rw(unsigned long addr, int numpages)
+{
+ return change_memory_attr(addr, numpages, SET_MEMORY_RW);
+}
+
+static inline int set_memory_nx(unsigned long addr, int numpages)
+{
+ return change_memory_attr(addr, numpages, SET_MEMORY_NX);
+}
+
+static inline int set_memory_x(unsigned long addr, int numpages)
+{
+ return change_memory_attr(addr, numpages, SET_MEMORY_X);
+}
+
+#endif
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 3b4e9e4e25ea..d8a08abde1ae 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -5,7 +5,7 @@
ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
-obj-y := fault.o mem.o pgtable.o mmap.o maccess.o \
+obj-y := fault.o mem.o pgtable.o mmap.o maccess.o pageattr.o \
init_$(BITS).o pgtable_$(BITS).o \
pgtable-frag.o ioremap.o ioremap_$(BITS).o \
init-common.o mmu_context.o drmem.o
diff --git a/arch/powerpc/mm/pageattr.c b/arch/powerpc/mm/pageattr.c
new file mode 100644
index 000000000000..9efcb01088da
--- /dev/null
+++ b/arch/powerpc/mm/pageattr.c
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * MMU-generic set_memory implementation for powerpc
+ *
+ * Copyright 2019, IBM Corporation.
+ */
+
+#include <linux/mm.h>
+#include <linux/set_memory.h>
+
+#include <asm/mmu.h>
+#include <asm/page.h>
+#include <asm/pgtable.h>
+
+
+/*
+ * Updates the attributes of a page in three steps:
+ *
+ * 1. invalidate the page table entry
+ * 2. flush the TLB
+ * 3. install the new entry with the updated attributes
+ *
+ * This is unsafe if the caller is attempting to change the mapping of the
+ * page it is executing from, or if another CPU is concurrently using the
+ * page being altered.
+ *
+ * TODO make the implementation resistant to this.
+ *
+ * NOTE: can be dangerous to call without STRICT_KERNEL_RWX
+ */
+static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
+{
+ long action = (long)data;
+ pte_t pte;
+
+ spin_lock(&init_mm.page_table_lock);
+
+ /* invalidate the PTE so it's safe to modify */
+ pte = ptep_get_and_clear(&init_mm, addr, ptep);
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+
+ /* modify the PTE bits as desired, then apply */
+ switch (action) {
+ case SET_MEMORY_RO:
+ pte = pte_wrprotect(pte);
+ break;
+ case SET_MEMORY_RW:
+ pte = pte_mkwrite(pte);
+ break;
+ case SET_MEMORY_NX:
+ pte = pte_exprotect(pte);
+ break;
+ case SET_MEMORY_X:
+ pte = pte_mkexec(pte);
+ break;
+ default:
+ WARN_ON_ONCE(1);
+ break;
+ }
+
+ set_pte_at(&init_mm, addr, ptep, pte);
+ spin_unlock(&init_mm.page_table_lock);
+
+ return 0;
+}
+
+int change_memory_attr(unsigned long addr, int numpages, long action)
+{
+ unsigned long start = ALIGN_DOWN(addr, PAGE_SIZE);
+ unsigned long sz = numpages * PAGE_SIZE;
+
+ if (!IS_ENABLED(CONFIG_STRICT_KERNEL_RWX))
+ return 0;
+
+ if (numpages <= 0)
+ return 0;
+
+#ifdef CONFIG_PPC_BOOK3S_64
+ if (WARN_ON_ONCE(!radix_enabled() &&
+ get_region_id(addr) == LINEAR_MAP_REGION_ID)) {
+ return -1;
+ }
+#endif
+
+ return apply_to_existing_page_range(&init_mm, start, sz,
+ change_page_attr, (void *)action);
+}
--
2.25.1
^ permalink raw reply related
* [PATCH v10 02/10] powerpc/lib/code-patching: Set up Strict RWX patching earlier
From: Jordan Niethe @ 2021-03-30 4:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ajd, cmr, npiggin, Jordan Niethe, naveen.n.rao, dja
In-Reply-To: <20210330045132.722243-1-jniethe5@gmail.com>
setup_text_poke_area() is a late init call so it runs before
mark_rodata_ro() and after the init calls. This lets all the init code
patching simply write to their locations. In the future, kprobes is
going to allocate its instruction pages RO which means they will need
setup_text__poke_area() to have been already called for their code
patching. However, init_kprobes() (which allocates and patches some
instruction pages) is an early init call so it happens before
setup_text__poke_area().
start_kernel() calls poking_init() before any of the init calls. On
powerpc, poking_init() is currently a nop. setup_text_poke_area() relies
on kernel virtual memory, cpu hotplug and per_cpu_areas being setup.
setup_per_cpu_areas(), boot_cpu_hotplug_init() and mm_init() are called
before poking_init().
Turn setup_text_poke_area() into poking_init().
Reviewed-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
v9: New to series
---
arch/powerpc/lib/code-patching.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 2333625b5e31..b28afa1133db 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -65,14 +65,11 @@ static int text_area_cpu_down(unsigned int cpu)
}
/*
- * Run as a late init call. This allows all the boot time patching to be done
- * simply by patching the code, and then we're called here prior to
- * mark_rodata_ro(), which happens after all init calls are run. Although
- * BUG_ON() is rude, in this case it should only happen if ENOMEM, and we judge
- * it as being preferable to a kernel that will crash later when someone tries
- * to use patch_instruction().
+ * Although BUG_ON() is rude, in this case it should only happen if ENOMEM, and
+ * we judge it as being preferable to a kernel that will crash later when
+ * someone tries to use patch_instruction().
*/
-static int __init setup_text_poke_area(void)
+int __init poking_init(void)
{
BUG_ON(!cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
"powerpc/text_poke:online", text_area_cpu_up,
@@ -80,7 +77,6 @@ static int __init setup_text_poke_area(void)
return 0;
}
-late_initcall(setup_text_poke_area);
/*
* This can be called for kernel text or a module.
--
2.25.1
^ permalink raw reply related
* [PATCH v10 03/10] powerpc: Always define MODULES_{VADDR,END}
From: Jordan Niethe @ 2021-03-30 4:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ajd, cmr, npiggin, Jordan Niethe, naveen.n.rao, dja
In-Reply-To: <20210330045132.722243-1-jniethe5@gmail.com>
If MODULES_{VADDR,END} are not defined set them to VMALLOC_START and
VMALLOC_END respectively. This reduces the need for special cases. For
example, powerpc's module_alloc() was previously predicated on
MODULES_VADDR being defined but now is unconditionally defined.
This will be useful reducing conditional code in other places that need
to allocate from the module region (i.e., kprobes).
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
v10: New to series
---
arch/powerpc/include/asm/pgtable.h | 5 +++++
arch/powerpc/kernel/module.c | 5 +----
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
index 4eed82172e33..014c2921f26a 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -167,6 +167,11 @@ struct seq_file;
void arch_report_meminfo(struct seq_file *m);
#endif /* CONFIG_PPC64 */
+#ifndef MODULES_VADDR
+#define MODULES_VADDR VMALLOC_START
+#define MODULES_END VMALLOC_END
+#endif
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_PGTABLE_H */
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index a211b0253cdb..f1fb58389d58 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -14,6 +14,7 @@
#include <asm/firmware.h>
#include <linux/sort.h>
#include <asm/setup.h>
+#include <linux/mm.h>
static LIST_HEAD(module_bug_list);
@@ -87,13 +88,9 @@ int module_finalize(const Elf_Ehdr *hdr,
return 0;
}
-#ifdef MODULES_VADDR
void *module_alloc(unsigned long size)
{
- BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
-
return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, GFP_KERNEL,
PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
__builtin_return_address(0));
}
-#endif
--
2.25.1
^ permalink raw reply related
* [PATCH v10 04/10] powerpc/kprobes: Mark newly allocated probes as ROX
From: Jordan Niethe @ 2021-03-30 4:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ajd, cmr, npiggin, naveen.n.rao, Jordan Niethe, dja
In-Reply-To: <20210330045132.722243-1-jniethe5@gmail.com>
From: Russell Currey <ruscur@russell.cc>
Add the arch specific insn page allocator for powerpc. This allocates
ROX pages if STRICT_KERNEL_RWX is enabled. These pages are only written
to with patch_instruction() which is able to write RO pages.
Reviewed-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
[jpn: Reword commit message, switch to __vmalloc_node_range()]
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
v9: - vmalloc_exec() no longer exists
- Set the page to RW before freeing it
v10: - use __vmalloc_node_range()
---
arch/powerpc/kernel/kprobes.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index 01ab2163659e..3ae27af9b094 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -25,6 +25,7 @@
#include <asm/sections.h>
#include <asm/inst.h>
#include <linux/uaccess.h>
+#include <linux/vmalloc.h>
DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
@@ -103,6 +104,19 @@ kprobe_opcode_t *kprobe_lookup_name(const char *name, unsigned int offset)
return addr;
}
+void *alloc_insn_page(void)
+{
+ if (IS_ENABLED(CONFIG_STRICT_KERNEL_RWX)) {
+ return __vmalloc_node_range(PAGE_SIZE, 1, MODULES_VADDR, MODULES_END,
+ GFP_KERNEL, PAGE_KERNEL_ROX, VM_FLUSH_RESET_PERMS,
+ NUMA_NO_NODE, __builtin_return_address(0));
+ } else {
+ return __vmalloc_node_range(PAGE_SIZE, 1, MODULES_VADDR, MODULES_END,
+ GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
+ NUMA_NO_NODE, __builtin_return_address(0));
+ }
+}
+
int arch_prepare_kprobe(struct kprobe *p)
{
int ret = 0;
--
2.25.1
^ permalink raw reply related
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