* Re: [PATCH v3 11/11] powerpc/64: use interrupt restart table to speed up return from interrupt
From: Nicholas Piggin @ 2021-06-16 1:20 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman
In-Reply-To: <87bl87tf86.fsf@mpe.ellerman.id.au>
Excerpts from Michael Ellerman's message of June 15, 2021 11:44 pm:
> Nicholas Piggin <npiggin@gmail.com> writes:
>> diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
>> index fe26f2fa0f3f..fbe94e2d5011 100644
>> --- a/arch/powerpc/lib/feature-fixups.c
>> +++ b/arch/powerpc/lib/feature-fixups.c
>> @@ -412,12 +430,19 @@ void do_entry_flush_fixups(enum l1d_flush_type types)
>> stop_machine(__do_entry_flush_fixups, &types, NULL);
>> }
>>
>> -void do_rfi_flush_fixups(enum l1d_flush_type types)
>> +static int __do_rfi_flush_fixups(void *data)
>> {
>> + enum l1d_flush_type types = *(enum l1d_flush_type *)data;
>> unsigned int instrs[3], *dest;
>> long *start, *end;
>> int i;
>>
>> + if (types & L1D_FLUSH_FALLBACK)
>> + rfi_exit_not_reentrant = true;
>> + else
>> + rfi_exit_not_reentrant = false;
>> + update_interrupt_exit();
>
> This is not happy:
Ah, needs a static_key_enable_cpuslocked. I'll fix.
Thanks,
Nick
>
> [ 0.000000][ T0] ============================================
> [ 0.000000][ T0] WARNING: possible recursive locking detected
> [ 0.000000][ T0] 5.13.0-rc2-00118-gca433a3a44e3 #1 Not tainted
> [ 0.000000][ T0] --------------------------------------------
> [ 0.000000][ T0] swapper/0 is trying to acquire lock:
> [ 0.000000][ T0] c00000000252fa10 (cpu_hotplug_lock){....}-{0:0}, at: static_key_enable+0x24/0x50
> [ 0.000000][ T0]
> [ 0.000000][ T0] but task is already holding lock:
> [ 0.000000][ T0] c00000000252fa10 (cpu_hotplug_lock){....}-{0:0}, at: stop_machine+0x2c/0x60
> [ 0.000000][ T0]
> [ 0.000000][ T0] other info that might help us debug this:
> [ 0.000000][ T0] Possible unsafe locking scenario:
> [ 0.000000][ T0]
> [ 0.000000][ T0] CPU0
> [ 0.000000][ T0] ----
> [ 0.000000][ T0] lock(cpu_hotplug_lock);
> [ 0.000000][ T0] lock(cpu_hotplug_lock);
> [ 0.000000][ T0]
> [ 0.000000][ T0] *** DEADLOCK ***
> [ 0.000000][ T0]
> [ 0.000000][ T0] May be due to missing lock nesting notation
> [ 0.000000][ T0]
> [ 0.000000][ T0] 1 lock held by swapper/0:
> [ 0.000000][ T0] #0: c00000000252fa10 (cpu_hotplug_lock){....}-{0:0}, at: stop_machine+0x2c/0x60
> [ 0.000000][ T0]
> [ 0.000000][ T0] stack backtrace:
> [ 0.000000][ T0] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.0-rc2-00118-gca433a3a44e3 #1
> [ 0.000000][ T0] Call Trace:
> [ 0.000000][ T0] [c0000000027db8f0] [c00000000093dd28] dump_stack+0xec/0x144 (unreliable)
> [ 0.000000][ T0] [c0000000027db940] [c0000000001ed5b4] __lock_acquire+0x1744/0x28b0
> [ 0.000000][ T0] [c0000000027dba70] [c0000000001ef338] lock_acquire+0x128/0x600
> [ 0.000000][ T0] [c0000000027dbb70] [c00000000015035c] cpus_read_lock+0x4c/0x170
> [ 0.000000][ T0] [c0000000027dbba0] [c0000000003c2594] static_key_enable+0x24/0x50
> [ 0.000000][ T0] [c0000000027dbbd0] [c0000000000ae87c] __do_rfi_flush_fixups+0x7c/0x300
> [ 0.000000][ T0] [c0000000027dbc80] [c0000000002ab7e4] stop_machine_cpuslocked+0xe4/0x200
> [ 0.000000][ T0] [c0000000027dbcf0] [c0000000002ab940] stop_machine+0x40/0x60
> [ 0.000000][ T0] [c0000000027dbd30] [c0000000000aef30] do_rfi_flush_fixups+0x30/0x50
> [ 0.000000][ T0] [c0000000027dbd60] [c000000000040890] setup_rfi_flush+0xa0/0x140
> [ 0.000000][ T0] [c0000000027dbdd0] [c00000000201c6c4] pnv_setup_arch+0x304/0x4ac
> [ 0.000000][ T0] [c0000000027dbe60] [c00000000200a31c] setup_arch+0x374/0x3c4
> [ 0.000000][ T0] [c0000000027dbee0] [c000000002003d08] start_kernel+0xb0/0x790
> [ 0.000000][ T0] [c0000000027dbf90] [c00000000000d79c] start_here_common+0x1c/0x600
> [ 0.000000][ T0] rfi-flush: patched 12 locations (fallback displacement flush)
>
>
> cheers
>
^ permalink raw reply
* Re: [PATCH v4 1/2] module: add elf_check_module_arch for module specific elf arch checks
From: Nicholas Piggin @ 2021-06-16 1:18 UTC (permalink / raw)
To: Jessica Yu; +Cc: Michal Suchánek, linuxppc-dev, linux-kernel
In-Reply-To: <YMiaZOqhHck9iy0n@p200300cbcf109700df096d564fe976c3.dip0.t-ipconnect.de>
Excerpts from Jessica Yu's message of June 15, 2021 10:17 pm:
> +++ Nicholas Piggin [15/06/21 12:05 +1000]:
>>Excerpts from Jessica Yu's message of June 14, 2021 10:06 pm:
>>> +++ Nicholas Piggin [11/06/21 19:39 +1000]:
>>>>The elf_check_arch() function is used to test usermode binaries, but
>>>>kernel modules may have more specific requirements. powerpc would like
>>>>to test for ABI version compatibility.
>>>>
>>>>Add an arch-overridable function elf_check_module_arch() that defaults
>>>>to elf_check_arch() and use it in elf_validity_check().
>>>>
>>>>Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>>>>[np: split patch, added changelog]
>>>>Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>>>---
>>>> include/linux/moduleloader.h | 5 +++++
>>>> kernel/module.c | 2 +-
>>>> 2 files changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>>diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
>>>>index 9e09d11ffe5b..fdc042a84562 100644
>>>>--- a/include/linux/moduleloader.h
>>>>+++ b/include/linux/moduleloader.h
>>>>@@ -13,6 +13,11 @@
>>>> * must be implemented by each architecture.
>>>> */
>>>>
>>>>+// Allow arch to optionally do additional checking of module ELF header
>>>>+#ifndef elf_check_module_arch
>>>>+#define elf_check_module_arch elf_check_arch
>>>>+#endif
>>>
>>> Hi Nicholas,
>>>
>>> Why not make elf_check_module_arch() consistent with the other
>>> arch-specific functions? Please see module_frob_arch_sections(),
>>> module_{init,exit}_section(), etc in moduleloader.h. That is, they are
>>> all __weak functions that are overridable by arches. We can maybe make
>>> elf_check_module_arch() a weak symbol, available for arches to
>>> override if they want to perform additional elf checks. Then we don't
>>> have to have this one-off #define.
>>
>>
>>Like this? I like it. Good idea.
>
> Yeah! Also, maybe we can alternatively make elf_check_module_arch() a
> separate check entirely so that the powerpc implementation doesn't
> have to include that extra elf_check_arch() call. Something like this maybe?
Yeah we can do that. Would you be okay if it goes via powerpc tree? If
yes, then we should get your Ack (or SOB because it seems to be entirely
your patch now :D)
Thanks,
Nick
>
> diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> index 9e09d11ffe5b..2f9ebd593b4f 100644
> --- a/include/linux/moduleloader.h
> +++ b/include/linux/moduleloader.h
> @@ -39,6 +39,9 @@ bool module_init_section(const char *name);
> */
> bool module_exit_section(const char *name);
>
> +/* Arch may override to do additional checking of ELF header architecture */
> +int elf_check_module_arch(Elf_Ehdr *hdr);
> +
> /*
> * Apply the given relocation to the (simplified) ELF. Return -error
> * or 0.
> diff --git a/kernel/module.c b/kernel/module.c
> index fdd6047728df..9963a979ed54 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2923,6 +2923,11 @@ static int validate_section_offset(struct load_info *info, Elf_Shdr *shdr)
> return 0;
> }
>
> +int __weak elf_check_module_arch(Elf_Ehdr *hdr)
> +{
> + return 1;
> +}
> +
> /*
> * Sanity checks against invalid binaries, wrong arch, weird elf version.
> *
> @@ -2941,6 +2946,7 @@ static int elf_validity_check(struct load_info *info)
> if (memcmp(info->hdr->e_ident, ELFMAG, SELFMAG) != 0
> || info->hdr->e_type != ET_REL
> || !elf_check_arch(info->hdr)
> + || !elf_check_module_arch(info->hdr)
> || info->hdr->e_shentsize != sizeof(Elf_Shdr))
> return -ENOEXEC;
>
>
>
^ permalink raw reply
* Re: [PATCH v2] selftests/powerpc: Always test lmw and stmw
From: Michael Ellerman @ 2021-06-16 1:06 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev; +Cc: Jordan Niethe
In-Reply-To: <20210615051009.538197-1-jniethe5@gmail.com>
Jordan Niethe <jniethe5@gmail.com> writes:
> Load Multiple Word (lmw) and Store Multiple Word (stmw) will raise an
> Alignment Exception:
> - Little Endian mode: always
> - Big Endian mode: address not word aligned
>
> These conditions do not depend on cache inhibited memory. Test the
> alignment handler emulation of these instructions regardless of if there
> is cache inhibited memory available or not.
>
> Commit dd3a44c06f7b ("selftests/powerpc: Only test lwm/stmw on big
> endian") stopped testing lmw/stmw on little endian because newer
> binutils (>= 2.36) will not assemble them in little endian mode. The
> kernel still emulates these instructions in little endian mode so use
> macros to generate them and test them.
>
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> ---
> v2: Use macros for lmw/stmw
> ---
> .../powerpc/alignment/alignment_handler.c | 101 +++++++++++++++++-
> .../selftests/powerpc/include/instructions.h | 10 ++
> 2 files changed, 106 insertions(+), 5 deletions(-)
Fails for me on BE?
test: test_alignment_handler_multiple
tags: git_version:v5.13-rc5-2025-g31e45305e351
Doing lmw: FAILED: Wrong Data
Doing stmw: FAILED: Wrong Data
failure: test_alignment_handler_multiple
cheers
^ permalink raw reply
* Re: [PATCH v4 2/4] lazy tlb: allow lazy tlb mm refcounting to be configurable
From: Nicholas Piggin @ 2021-06-16 1:02 UTC (permalink / raw)
To: Andrew Morton, Andy Lutomirski
Cc: linux-arch, Rik van Riel, Linus Torvalds, Randy Dunlap,
linux-kernel, linux-mm, linuxppc-dev
In-Reply-To: <3b9eb877-5d1e-d565-5577-575229d18b6e@kernel.org>
Excerpts from Andy Lutomirski's message of June 16, 2021 10:14 am:
> On 6/14/21 5:55 PM, Nicholas Piggin wrote:
>> Excerpts from Andy Lutomirski's message of June 15, 2021 2:20 am:
>>> Replying to several emails at once...
>>>
>
>>
>> So the only documentation relating to the current active_mm value or
>> refcounting is that it may not match what the x86 specific code is
>> doing?
>>
>> All this complexity you accuse me of adding is entirely in x86 code.
>> On other architectures, it's very simple and understandable, and
>> documented. I don't know how else to explain this.
>
> And the docs you referred me to will be *wrong* with your patches
> applied. They are your patches, and they break the semantics.
No they aren't wrong, I've documented the shootdown refcounting scheme
and Linus' historical email is still right about the active_mm concept,
and the refcounting details still match the CONFIG_MMU_TLB_REFCOUNT=y
case.
If you have some particular place you would like to see more
documentation added, please tell me where I'll add something before
the series gets upstreamed.
>>>>>>
>>>>>>> With your patch applied:
>>>>>>>
>>>>>>> To support all that, the "struct mm_struct" now has two counters: a
>>>>>>> "mm_users" counter that is how many "real address space users" there are,
>>>>>>> and a "mm_count" counter that is the number of "lazy" users (ie anonymous
>>>>>>> users) plus one if there are any real users.
>>>>>>>
>>>>>>> isn't even true any more.
>>>>>>
>>>>>> Well yeah but the active_mm concept hasn't changed. The refcounting
>>>>>> change is hopefully reasonably documented?
>>>
>>> active_mm is *only* refcounting in the core code. See below.
>>
>> It's just not. It's passed in to switch_mm. Most architectures except
>> for x86 require this.
>>
>
> Sorry, I was obviously blatantly wrong. Let me say it differently.
> active_mm does two things:
>
> 1. It keeps an mm alive via a refcounting scheme.
>
> 2. It passes a parameter to switch_mm() to remind the arch code what the
> most recently switch-to mm was.
>
> #2 is basically useless. An architecture can handle *that* with a
> percpu variable and two lines of code.
>
> If you are getting rid of functionality #1 in the core code via a new
> arch opt-out, please get rid of #2 as well. *Especially* because, when
> the arch asks the core code to stop refcounting active_mm, there is
> absolutely nothing guaranteeing that the parameter that the core code
> will pass to switch_mm() points to memory that hasn't been freed and
> reused for another purpose.
You're confused about the patch. It's not opting out of lazy tlb mm or
opting out of active_mm, it is changing how the refcounting is done.
You were just before trying to tell me it would make the code simpler to
remove it, but it clearly wouldn't if powerpc just had to reimplement it
in arch code anyway, would it?
powerpc is not going to add code to reimplement the exact same thing as
active_mm, because it uses active_mm and so does everyone else. For the
last time I'm not going to change that.
That is something x86 wants. This series is not for x86. It doesn't
change anything that x86 does. I have kindly tried to give you
suggestions and patches about what you might do with x86, and it can
easily be changed, but that is not the purpose of my patch. Please don't
reply again telling me to get rid of active_mm. We'll draw a line under
this and move on.
>>> I don't understand what contract you're talking about. The core code
>>> maintains an active_mm counter and keeps that mm_struct from
>>> disappearing. That's *it*. The core code does not care that active_mm
>>> is active, and x86 provides evidence of that -- on x86,
>>> current->active_mm may well be completely unused.
>>
>> I already acknowledged archs can do their own thing under the covers if
>> they want.
>
> No.
>
> I am *not* going to write x86 patches that use your feature in a way
> that will cause the core code to pass around a complete garbage pointer
> to an mm_struct that is completely unreferenced and may well be deleted.
> Doing something private in arch code is one thing. Doing something
> that causes basic common sense to be violated in core code is another
> thing entirely.
I'm talking about the relationship between core code's idea of active_mm
and the arch's idea as it stands now. I'm not talking about what you might
do with x86.
The whole point of this was that you have been operating under the
misconception that active_mm is not a core kernel concept, because x86
has gone and done its own thing and doesn't use it. That does not mean
it is not a core kernel concept!
>
>>>
>>> static inline void do_switch_mm(struct task_struct *prev_task, ...)
>>> {
>>> #ifdef CONFIG_MMU_TLB_REFCOUNT
>>> switch_mm(...);
>>> #else
>>> switch_mm(fewer parameters);
>>> /* or pass NULL or whatever. */
>>> #endif
>>> }
>>
>> And prev_task comes from active_mm, ergo core code requires the concept
>> of active_mm.
>
> I don't see why this concept is hard. We are literally quibbling about
> this single line of core code in kernel/sched/core.c:
>
> switch_mm_irqs_off(prev->active_mm, next->mm, next);
>
> This is not rocket science. There are any number of ways to fix it.
> For example:
>
> #ifdef CONFIG_MMU_TLB_REFCOUNT
> switch_mm_irqs_off(prev->active_mm, next->mm, next);
> #else
> switch_mm_irqs_off(NULL, next->mm, next);
> #endif
>
> If you don't like the NULL, then make the signature depend on the config
> option.
>
> What you may not do is what your patch actually does:
>
> switch_mm_irqs_off(random invalid pointer, next->mm, next);
You're totally confused about the code, and my patch series. That's not
what it does at all. Unless you have spotted a bug, in which case point
it out.
>
> Now maybe it works because powerpc's lifecycle rules happen to keep
> active_mm alive, but I haven't verified it. x86's lifecycle rules *do not*.
>
>>>>
>>>> That's understandable, but please redirect your objections to the proper
>>>> place. git blame suggests 3d28ebceaffab.
>>>
>>> Thanks for the snark.
>>
>> Is it not true? I don't mean that one patch causing all the x86
>> complexity or even making the situation worse itself. But you seem to be
>> asking my series to do things that really apply to the x86 changes over
>> the past few years that got us here.
>
> With just my patch from 4.15 applied, task->active_mm points to an
> actual mm_struct, and that mm_struct will not be freed early. If I opt
> x86 into your patch's new behavior, then task->active_mm may be freed.
>
> akpm, please drop this series until it's fixed. It's a core change to
> better support arch usecases, but it's unnecessarily fragile, and there
> is already an arch maintainer pointing out that it's inadequate to
> robustly support arch usecases. There is no reason to merge it in its
> present state.
>
No, you've been sniping these for nearly a year now, and I've been pretty
accommodating not pushing it upstream, and trying to get anything out of
you, a patch or an actual description of the problem, but it's like
getting blood from a stone. I've tried to ask what help x86 needs, but
nothing. You didn't even reply to my (actual working) patch or questions
about it in the last comment! Doing that then throwing out NAK like it's
a magic word is pretty rude really.
The series is fine, it's documented, it works well, it solves a problem
the core code changes are small and reusable, and nobody has pointed out
a bug.
So at this point, just get over it. Do some patches for x86 on top of it
later when you have some time. Or Rik might. None of the patches in my
series prevents that. I'll be happy to review your changes or adjust
some of the code added in this series so it's usable by x86 if you need.
The x86 work could have bee done already with the time bickering about
this.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v4 2/4] lazy tlb: allow lazy tlb mm refcounting to be configurable
From: Andy Lutomirski @ 2021-06-16 0:14 UTC (permalink / raw)
To: Nicholas Piggin, Andrew Morton
Cc: linux-arch, Rik van Riel, Linus Torvalds, Randy Dunlap,
linux-kernel, linux-mm, linuxppc-dev
In-Reply-To: <1623715482.4lskm3cx10.astroid@bobo.none>
On 6/14/21 5:55 PM, Nicholas Piggin wrote:
> Excerpts from Andy Lutomirski's message of June 15, 2021 2:20 am:
>> Replying to several emails at once...
>>
>
> So the only documentation relating to the current active_mm value or
> refcounting is that it may not match what the x86 specific code is
> doing?
>
> All this complexity you accuse me of adding is entirely in x86 code.
> On other architectures, it's very simple and understandable, and
> documented. I don't know how else to explain this.
And the docs you referred me to will be *wrong* with your patches
applied. They are your patches, and they break the semantics.
>
>>>>>
>>>>>> With your patch applied:
>>>>>>
>>>>>> To support all that, the "struct mm_struct" now has two counters: a
>>>>>> "mm_users" counter that is how many "real address space users" there are,
>>>>>> and a "mm_count" counter that is the number of "lazy" users (ie anonymous
>>>>>> users) plus one if there are any real users.
>>>>>>
>>>>>> isn't even true any more.
>>>>>
>>>>> Well yeah but the active_mm concept hasn't changed. The refcounting
>>>>> change is hopefully reasonably documented?
>>
>> active_mm is *only* refcounting in the core code. See below.
>
> It's just not. It's passed in to switch_mm. Most architectures except
> for x86 require this.
>
Sorry, I was obviously blatantly wrong. Let me say it differently.
active_mm does two things:
1. It keeps an mm alive via a refcounting scheme.
2. It passes a parameter to switch_mm() to remind the arch code what the
most recently switch-to mm was.
#2 is basically useless. An architecture can handle *that* with a
percpu variable and two lines of code.
If you are getting rid of functionality #1 in the core code via a new
arch opt-out, please get rid of #2 as well. *Especially* because, when
the arch asks the core code to stop refcounting active_mm, there is
absolutely nothing guaranteeing that the parameter that the core code
will pass to switch_mm() points to memory that hasn't been freed and
reused for another purpose.
>>>>> I might not have been clear. Core code doesn't need active_mm if
>>>>> active_mm somehow goes away. I'm saying active_mm can't go away because
>>>>> it's needed to support (most) archs that do lazy tlb mm switching.
>>>>>
>>>>> The part I don't understand is when you say it can just go away. How?
>>
>> #ifdef CONFIG_MMU_TLB_REFCOUNT
>> struct mm_struct *active_mm;
>> #endif
>
> Thanks for returning the snark.
That wasn't intended to be snark. It was a literal suggestion, and, in
fact, it's *exactly* what I'm asking you to do to fix your patches.
>> I don't understand what contract you're talking about. The core code
>> maintains an active_mm counter and keeps that mm_struct from
>> disappearing. That's *it*. The core code does not care that active_mm
>> is active, and x86 provides evidence of that -- on x86,
>> current->active_mm may well be completely unused.
>
> I already acknowledged archs can do their own thing under the covers if
> they want.
No.
I am *not* going to write x86 patches that use your feature in a way
that will cause the core code to pass around a complete garbage pointer
to an mm_struct that is completely unreferenced and may well be deleted.
Doing something private in arch code is one thing. Doing something
that causes basic common sense to be violated in core code is another
thing entirely.
>>
>> static inline void do_switch_mm(struct task_struct *prev_task, ...)
>> {
>> #ifdef CONFIG_MMU_TLB_REFCOUNT
>> switch_mm(...);
>> #else
>> switch_mm(fewer parameters);
>> /* or pass NULL or whatever. */
>> #endif
>> }
>
> And prev_task comes from active_mm, ergo core code requires the concept
> of active_mm.
I don't see why this concept is hard. We are literally quibbling about
this single line of core code in kernel/sched/core.c:
switch_mm_irqs_off(prev->active_mm, next->mm, next);
This is not rocket science. There are any number of ways to fix it.
For example:
#ifdef CONFIG_MMU_TLB_REFCOUNT
switch_mm_irqs_off(prev->active_mm, next->mm, next);
#else
switch_mm_irqs_off(NULL, next->mm, next);
#endif
If you don't like the NULL, then make the signature depend on the config
option.
What you may not do is what your patch actually does:
switch_mm_irqs_off(random invalid pointer, next->mm, next);
Now maybe it works because powerpc's lifecycle rules happen to keep
active_mm alive, but I haven't verified it. x86's lifecycle rules *do not*.
>>>
>>> That's understandable, but please redirect your objections to the proper
>>> place. git blame suggests 3d28ebceaffab.
>>
>> Thanks for the snark.
>
> Is it not true? I don't mean that one patch causing all the x86
> complexity or even making the situation worse itself. But you seem to be
> asking my series to do things that really apply to the x86 changes over
> the past few years that got us here.
With just my patch from 4.15 applied, task->active_mm points to an
actual mm_struct, and that mm_struct will not be freed early. If I opt
x86 into your patch's new behavior, then task->active_mm may be freed.
akpm, please drop this series until it's fixed. It's a core change to
better support arch usecases, but it's unnecessarily fragile, and there
is already an arch maintainer pointing out that it's inadequate to
robustly support arch usecases. There is no reason to merge it in its
present state.
^ permalink raw reply
* Re: [RFC] powerpc/pseries: Interface to represent PAPR firmware attributes
From: Michael Ellerman @ 2021-06-16 0:03 UTC (permalink / raw)
To: Fabiano Rosas, Pratik Sampat, benh, paulus, linuxppc-dev, kvm-ppc,
linux-kernel, pratik.r.sampat
In-Reply-To: <87tum6vb58.fsf@linux.ibm.com>
Fabiano Rosas <farosas@linux.ibm.com> writes:
> Pratik Sampat <psampat@linux.ibm.com> writes:
...
>>>
>>>> The new H_CALL exports information in direct string value format, hence
>>>> a new interface has been introduced in /sys/firmware/papr to export
>>> Hm.. Maybe this should be something less generic than "papr"?
>>
>> The interface naming was inspired from /sys/firmware/opal's naming convention.
>> We believed the name PAPR could serve as more generic name to be used by both
>> Linux running on PHYP and linux on KVM.
>
> Right, I agree with that rationale, but /opal has identifiable elements
> in it whereas /papr would have the generic "attr_X_name", which does not
> give much hint about what they are.
>
> We also expect people to iterate the "attr_X_*" files, so if we decide
> to add something else under /papr in the future, that would potentially
> cause issues with any tool that just lists the content of the directory.
>
> So maybe we should be proactive and put the hcall stuff inside a
> subdirectory already. /papr/energy_scale_attrs comes to mind, but I
> don't have a strong opinion on the particular name.
Maybe we should use the descriptive part of the hcall.
So H_GET_ENERGY_SCALE_INFO -> ../papr/energy_scale_info/
That should help avoid any naming confusion, because every hcall should
have a unique name.
In future if there's ever a H_GET_ENERGY_SCALE_INFO_2 we would then have
to decide if we expose that as a separate directory, or more likely we
would handle that in the kernel and continue to use the existing sysfs
name.
...
> Based on all the new information you provided, I'd say present all the
> data and group it under the ID:
>
> /sys/firmware/papr/energy_scale_attrs/
> |-- <id>/
> |-- desc
> |-- value
> |-- value_desc
> |-- <id>/
> |-- desc
> |-- value
> |-- value_desc
Yeah that seems reasonable.
I'd think we should just omit the value_desc if it's empty.
cheers
^ permalink raw reply
* + mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t.patch added to -mm tree
From: akpm @ 2021-06-15 23:38 UTC (permalink / raw)
To: aneesh.kumar, linux-alpha, linux-arch, linux-arm-kernel,
linux-ia64, linux-kernel, linux-m68k, linux-mips, linux-parisc,
linux-riscv, linux-sh, linux-um, linuxppc-dev, mm-commits,
sparclinux
The patch titled
Subject: mm: rename p4d_page_vaddr to p4d_pgtable and make it return pud_t *
has been added to the -mm tree. Its filename is
mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t.patch
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Subject: mm: rename p4d_page_vaddr to p4d_pgtable and make it return pud_t *
No functional change in this patch.
Link: https://lkml.kernel.org/r/20210615110859.320299-2-aneesh.kumar@linux.ibm.com
Link: https://lore.kernel.org/linuxppc-dev/CAHk-=wi+J+iodze9FtjM3Zi4j4OeS+qqbKxME9QN4roxPEXH9Q@mail.gmail.com/
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: <linux-alpha@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <linux-ia64@vger.kernel.org>
Cc: <linux-m68k@lists.linux-m68k.org>
Cc: <linux-mips@vger.kernel.org>
Cc: <linux-parisc@vger.kernel.org>
Cc: <linuxppc-dev@lists.ozlabs.org>
Cc: <linux-riscv@lists.infradead.org>
Cc: <linux-sh@vger.kernel.org>
Cc: <sparclinux@vger.kernel.org>
Cc: <linux-um@lists.infradead.org>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/arm64/include/asm/pgtable.h | 4 ++--
arch/ia64/include/asm/pgtable.h | 2 +-
arch/mips/include/asm/pgtable-64.h | 4 ++--
arch/powerpc/include/asm/book3s/64/pgtable.h | 5 ++++-
arch/powerpc/include/asm/nohash/64/pgtable-4k.h | 6 +++++-
arch/powerpc/mm/book3s64/radix_pgtable.c | 2 +-
arch/powerpc/mm/pgtable_64.c | 2 +-
arch/sparc/include/asm/pgtable_64.h | 4 ++--
arch/x86/include/asm/pgtable.h | 4 ++--
arch/x86/mm/init_64.c | 4 ++--
include/asm-generic/pgtable-nop4d.h | 2 +-
include/asm-generic/pgtable-nopud.h | 2 +-
include/linux/pgtable.h | 2 +-
13 files changed, 25 insertions(+), 18 deletions(-)
--- a/arch/arm64/include/asm/pgtable.h~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/arch/arm64/include/asm/pgtable.h
@@ -694,9 +694,9 @@ static inline phys_addr_t p4d_page_paddr
return __p4d_to_phys(p4d);
}
-static inline unsigned long p4d_page_vaddr(p4d_t p4d)
+static inline pud_t *p4d_pgtable(p4d_t p4d)
{
- return (unsigned long)__va(p4d_page_paddr(p4d));
+ return (pud_t *)__va(p4d_page_paddr(p4d));
}
/* Find an entry in the frst-level page table. */
--- a/arch/ia64/include/asm/pgtable.h~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/arch/ia64/include/asm/pgtable.h
@@ -281,7 +281,7 @@ ia64_phys_addr_valid (unsigned long addr
#define p4d_bad(p4d) (!ia64_phys_addr_valid(p4d_val(p4d)))
#define p4d_present(p4d) (p4d_val(p4d) != 0UL)
#define p4d_clear(p4dp) (p4d_val(*(p4dp)) = 0UL)
-#define p4d_page_vaddr(p4d) ((unsigned long) __va(p4d_val(p4d) & _PFN_MASK))
+#define p4d_pgtable(p4d) ((pud_t *) __va(p4d_val(p4d) & _PFN_MASK))
#define p4d_page(p4d) virt_to_page((p4d_val(p4d) + PAGE_OFFSET))
#endif
--- a/arch/mips/include/asm/pgtable-64.h~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/arch/mips/include/asm/pgtable-64.h
@@ -209,9 +209,9 @@ static inline void p4d_clear(p4d_t *p4dp
p4d_val(*p4dp) = (unsigned long)invalid_pud_table;
}
-static inline unsigned long p4d_page_vaddr(p4d_t p4d)
+static inline pud_t *p4d_pgtable(p4d_t p4d)
{
- return p4d_val(p4d);
+ return (pud_t *)p4d_val(p4d);
}
#define p4d_phys(p4d) virt_to_phys((void *)p4d_val(p4d))
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -1048,7 +1048,10 @@ extern struct page *p4d_page(p4d_t p4d);
/* Pointers in the page table tree are physical addresses */
#define __pgtable_ptr_val(ptr) __pa(ptr)
-#define p4d_page_vaddr(p4d) __va(p4d_val(p4d) & ~P4D_MASKED_BITS)
+static inline pud_t *p4d_pgtable(p4d_t p4d)
+{
+ return (pud_t *)__va(p4d_val(p4d) & ~P4D_MASKED_BITS);
+}
static inline pmd_t *pud_pgtable(pud_t pud)
{
--- a/arch/powerpc/include/asm/nohash/64/pgtable-4k.h~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/arch/powerpc/include/asm/nohash/64/pgtable-4k.h
@@ -56,10 +56,14 @@
#define p4d_none(p4d) (!p4d_val(p4d))
#define p4d_bad(p4d) (p4d_val(p4d) == 0)
#define p4d_present(p4d) (p4d_val(p4d) != 0)
-#define p4d_page_vaddr(p4d) (p4d_val(p4d) & ~P4D_MASKED_BITS)
#ifndef __ASSEMBLY__
+static inline pud_t *p4d_pgtable(p4d_t p4d)
+{
+ return (pud_t *) (p4d_val(p4d) & ~P4D_MASKED_BITS);
+}
+
static inline void p4d_clear(p4d_t *p4dp)
{
*p4dp = __p4d(0);
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -860,7 +860,7 @@ static void __meminit remove_pagetable(u
continue;
}
- pud_base = (pud_t *)p4d_page_vaddr(*p4d);
+ pud_base = p4d_pgtable(*p4d);
remove_pud_table(pud_base, addr, next);
free_pud_table(pud_base, p4d);
}
--- a/arch/powerpc/mm/pgtable_64.c~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/arch/powerpc/mm/pgtable_64.c
@@ -105,7 +105,7 @@ struct page *p4d_page(p4d_t p4d)
VM_WARN_ON(!p4d_huge(p4d));
return pte_page(p4d_pte(p4d));
}
- return virt_to_page(p4d_page_vaddr(p4d));
+ return virt_to_page(p4d_pgtable(p4d));
}
#endif
--- a/arch/sparc/include/asm/pgtable_64.h~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/arch/sparc/include/asm/pgtable_64.h
@@ -856,8 +856,8 @@ static inline pmd_t *pud_pgtable(pud_t p
#define pmd_clear(pmdp) (pmd_val(*(pmdp)) = 0UL)
#define pud_present(pud) (pud_val(pud) != 0U)
#define pud_clear(pudp) (pud_val(*(pudp)) = 0UL)
-#define p4d_page_vaddr(p4d) \
- ((unsigned long) __va(p4d_val(p4d)))
+#define p4d_pgtable(p4d) \
+ ((pud_t *) __va(p4d_val(p4d)))
#define p4d_present(p4d) (p4d_val(p4d) != 0U)
#define p4d_clear(p4dp) (p4d_val(*(p4dp)) = 0UL)
--- a/arch/x86/include/asm/pgtable.h~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/arch/x86/include/asm/pgtable.h
@@ -906,9 +906,9 @@ static inline int p4d_present(p4d_t p4d)
return p4d_flags(p4d) & _PAGE_PRESENT;
}
-static inline unsigned long p4d_page_vaddr(p4d_t p4d)
+static inline pud_t *p4d_pgtable(p4d_t p4d)
{
- return (unsigned long)__va(p4d_val(p4d) & p4d_pfn_mask(p4d));
+ return (pud_t *)__va(p4d_val(p4d) & p4d_pfn_mask(p4d));
}
/*
--- a/arch/x86/mm/init_64.c~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/arch/x86/mm/init_64.c
@@ -195,8 +195,8 @@ static void sync_global_pgds_l4(unsigned
spin_lock(pgt_lock);
if (!p4d_none(*p4d_ref) && !p4d_none(*p4d))
- BUG_ON(p4d_page_vaddr(*p4d)
- != p4d_page_vaddr(*p4d_ref));
+ BUG_ON(p4d_pgtable(*p4d)
+ != p4d_pgtable(*p4d_ref));
if (p4d_none(*p4d))
set_p4d(p4d, *p4d_ref);
--- a/include/asm-generic/pgtable-nop4d.h~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/include/asm-generic/pgtable-nop4d.h
@@ -42,7 +42,7 @@ static inline p4d_t *p4d_offset(pgd_t *p
#define __p4d(x) ((p4d_t) { __pgd(x) })
#define pgd_page(pgd) (p4d_page((p4d_t){ pgd }))
-#define pgd_page_vaddr(pgd) (p4d_page_vaddr((p4d_t){ pgd }))
+#define pgd_page_vaddr(pgd) (p4d_pgtable((p4d_t){ pgd }))
/*
* allocating and freeing a p4d is trivial: the 1-entry p4d is
--- a/include/asm-generic/pgtable-nopud.h~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/include/asm-generic/pgtable-nopud.h
@@ -49,7 +49,7 @@ static inline pud_t *pud_offset(p4d_t *p
#define __pud(x) ((pud_t) { __p4d(x) })
#define p4d_page(p4d) (pud_page((pud_t){ p4d }))
-#define p4d_page_vaddr(p4d) (pud_pgtable((pud_t){ p4d }))
+#define p4d_pgtable(p4d) ((pud_t *)(pud_pgtable((pud_t){ p4d })))
/*
* allocating and freeing a pud is trivial: the 1-entry pud is
--- a/include/linux/pgtable.h~mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t
+++ a/include/linux/pgtable.h
@@ -114,7 +114,7 @@ static inline pmd_t *pmd_offset(pud_t *p
#ifndef pud_offset
static inline pud_t *pud_offset(p4d_t *p4d, unsigned long address)
{
- return (pud_t *)p4d_page_vaddr(*p4d) + pud_index(address);
+ return p4d_pgtable(*p4d) + pud_index(address);
}
#define pud_offset pud_offset
#endif
_
Patches currently in -mm which might be from aneesh.kumar@linux.ibm.com are
mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t.patch
mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t.patch
^ permalink raw reply
* + mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t.patch added to -mm tree
From: akpm @ 2021-06-15 23:38 UTC (permalink / raw)
To: aneesh.kumar, linux-alpha, linux-arch, linux-arm-kernel,
linux-ia64, linux-kernel, linux-m68k, linux-mips, linux-parisc,
linux-riscv, linux-sh, linux-um, linuxppc-dev, mm-commits,
sparclinux
The patch titled
Subject: mm: rename pud_page_vaddr to pud_pgtable and make it return pmd_t *
has been added to the -mm tree. Its filename is
mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t.patch
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Subject: mm: rename pud_page_vaddr to pud_pgtable and make it return pmd_t *
No functional change in this patch.
Link: https://lkml.kernel.org/r/20210615110859.320299-1-aneesh.kumar@linux.ibm.com
Link: https://lore.kernel.org/linuxppc-dev/CAHk-=wi+J+iodze9FtjM3Zi4j4OeS+qqbKxME9QN4roxPEXH9Q@mail.gmail.com/
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: <linux-alpha@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <linux-ia64@vger.kernel.org>
Cc: <linux-m68k@lists.linux-m68k.org>
Cc: <linux-mips@vger.kernel.org>
Cc: <linux-parisc@vger.kernel.org>
Cc: <linuxppc-dev@lists.ozlabs.org>
Cc: <linux-riscv@lists.infradead.org>
Cc: <linux-sh@vger.kernel.org>
Cc: <sparclinux@vger.kernel.org>
Cc: <linux-um@lists.infradead.org>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/alpha/include/asm/pgtable.h | 8 +++++---
arch/arm/include/asm/pgtable-3level.h | 2 +-
arch/arm64/include/asm/pgtable.h | 4 ++--
arch/ia64/include/asm/pgtable.h | 2 +-
arch/m68k/include/asm/motorola_pgtable.h | 2 +-
arch/mips/include/asm/pgtable-64.h | 4 ++--
arch/parisc/include/asm/pgtable.h | 4 ++--
arch/powerpc/include/asm/book3s/64/pgtable.h | 6 +++++-
arch/powerpc/include/asm/nohash/64/pgtable.h | 6 +++++-
arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++--
arch/powerpc/mm/pgtable_64.c | 2 +-
arch/riscv/include/asm/pgtable-64.h | 4 ++--
arch/sh/include/asm/pgtable-3level.h | 4 ++--
arch/sparc/include/asm/pgtable_32.h | 4 ++--
arch/sparc/include/asm/pgtable_64.h | 6 +++---
arch/um/include/asm/pgtable-3level.h | 2 +-
arch/x86/include/asm/pgtable.h | 4 ++--
arch/x86/mm/pat/set_memory.c | 4 ++--
arch/x86/mm/pgtable.c | 2 +-
include/asm-generic/pgtable-nopmd.h | 2 +-
include/asm-generic/pgtable-nopud.h | 2 +-
include/linux/pgtable.h | 2 +-
22 files changed, 45 insertions(+), 35 deletions(-)
--- a/arch/alpha/include/asm/pgtable.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/alpha/include/asm/pgtable.h
@@ -236,8 +236,10 @@ pmd_page_vaddr(pmd_t pmd)
#define pmd_page(pmd) (pfn_to_page(pmd_val(pmd) >> 32))
#define pud_page(pud) (pfn_to_page(pud_val(pud) >> 32))
-extern inline unsigned long pud_page_vaddr(pud_t pgd)
-{ return PAGE_OFFSET + ((pud_val(pgd) & _PFN_MASK) >> (32-PAGE_SHIFT)); }
+static inline pmd_t *pud_pgtable(pud_t pgd)
+{
+ return (pmd_t *)(PAGE_OFFSET + ((pud_val(pgd) & _PFN_MASK) >> (32-PAGE_SHIFT)));
+}
extern inline int pte_none(pte_t pte) { return !pte_val(pte); }
extern inline int pte_present(pte_t pte) { return pte_val(pte) & _PAGE_VALID; }
@@ -287,7 +289,7 @@ extern inline pte_t pte_mkyoung(pte_t pt
/* Find an entry in the second-level page table.. */
extern inline pmd_t * pmd_offset(pud_t * dir, unsigned long address)
{
- pmd_t *ret = (pmd_t *) pud_page_vaddr(*dir) + ((address >> PMD_SHIFT) & (PTRS_PER_PAGE - 1));
+ pmd_t *ret = pud_pgtable(*dir) + ((address >> PMD_SHIFT) & (PTRS_PER_PAGE - 1));
smp_rmb(); /* see above */
return ret;
}
--- a/arch/arm64/include/asm/pgtable.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/arm64/include/asm/pgtable.h
@@ -633,9 +633,9 @@ static inline phys_addr_t pud_page_paddr
return __pud_to_phys(pud);
}
-static inline unsigned long pud_page_vaddr(pud_t pud)
+static inline pmd_t *pud_pgtable(pud_t pud)
{
- return (unsigned long)__va(pud_page_paddr(pud));
+ return (pmd_t *)__va(pud_page_paddr(pud));
}
/* Find an entry in the second-level page table. */
--- a/arch/arm/include/asm/pgtable-3level.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/arm/include/asm/pgtable-3level.h
@@ -130,7 +130,7 @@
flush_pmd_entry(pudp); \
} while (0)
-static inline pmd_t *pud_page_vaddr(pud_t pud)
+static inline pmd_t *pud_pgtable(pud_t pud)
{
return __va(pud_val(pud) & PHYS_MASK & (s32)PAGE_MASK);
}
--- a/arch/ia64/include/asm/pgtable.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/ia64/include/asm/pgtable.h
@@ -273,7 +273,7 @@ ia64_phys_addr_valid (unsigned long addr
#define pud_bad(pud) (!ia64_phys_addr_valid(pud_val(pud)))
#define pud_present(pud) (pud_val(pud) != 0UL)
#define pud_clear(pudp) (pud_val(*(pudp)) = 0UL)
-#define pud_page_vaddr(pud) ((unsigned long) __va(pud_val(pud) & _PFN_MASK))
+#define pud_pgtable(pud) ((pmd_t *) __va(pud_val(pud) & _PFN_MASK))
#define pud_page(pud) virt_to_page((pud_val(pud) + PAGE_OFFSET))
#if CONFIG_PGTABLE_LEVELS == 4
--- a/arch/m68k/include/asm/motorola_pgtable.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/m68k/include/asm/motorola_pgtable.h
@@ -131,7 +131,7 @@ static inline void pud_set(pud_t *pudp,
#define __pte_page(pte) ((unsigned long)__va(pte_val(pte) & PAGE_MASK))
#define pmd_page_vaddr(pmd) ((unsigned long)__va(pmd_val(pmd) & _TABLE_MASK))
-#define pud_page_vaddr(pud) ((unsigned long)__va(pud_val(pud) & _TABLE_MASK))
+#define pud_pgtable(pud) ((pmd_t *)__va(pud_val(pud) & _TABLE_MASK))
#define pte_none(pte) (!pte_val(pte))
--- a/arch/mips/include/asm/pgtable-64.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/mips/include/asm/pgtable-64.h
@@ -313,9 +313,9 @@ static inline void pud_clear(pud_t *pudp
#endif
#ifndef __PAGETABLE_PMD_FOLDED
-static inline unsigned long pud_page_vaddr(pud_t pud)
+static inline pmd_t *pud_pgtable(pud_t pud)
{
- return pud_val(pud);
+ return (pmd_t *)pud_val(pud);
}
#define pud_phys(pud) virt_to_phys((void *)pud_val(pud))
#define pud_page(pud) (pfn_to_page(pud_phys(pud) >> PAGE_SHIFT))
--- a/arch/parisc/include/asm/pgtable.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/parisc/include/asm/pgtable.h
@@ -322,8 +322,8 @@ static inline void pmd_clear(pmd_t *pmd)
#if CONFIG_PGTABLE_LEVELS == 3
-#define pud_page_vaddr(pud) ((unsigned long) __va(pud_address(pud)))
-#define pud_page(pud) virt_to_page((void *)pud_page_vaddr(pud))
+#define pud_pgtable(pud) ((pmd_t *) __va(pud_address(pud)))
+#define pud_page(pud) virt_to_page((void *)pud_pgtable(pud))
/* For 64 bit we have three level tables */
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -1048,9 +1048,13 @@ extern struct page *p4d_page(p4d_t p4d);
/* Pointers in the page table tree are physical addresses */
#define __pgtable_ptr_val(ptr) __pa(ptr)
-#define pud_page_vaddr(pud) __va(pud_val(pud) & ~PUD_MASKED_BITS)
#define p4d_page_vaddr(p4d) __va(p4d_val(p4d) & ~P4D_MASKED_BITS)
+static inline pmd_t *pud_pgtable(pud_t pud)
+{
+ return (pmd_t *)__va(pud_val(pud) & ~PUD_MASKED_BITS);
+}
+
#define pte_ERROR(e) \
pr_err("%s:%d: bad pte %08lx.\n", __FILE__, __LINE__, pte_val(e))
#define pmd_ERROR(e) \
--- a/arch/powerpc/include/asm/nohash/64/pgtable.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/powerpc/include/asm/nohash/64/pgtable.h
@@ -162,7 +162,11 @@ static inline void pud_clear(pud_t *pudp
#define pud_bad(pud) (!is_kernel_addr(pud_val(pud)) \
|| (pud_val(pud) & PUD_BAD_BITS))
#define pud_present(pud) (pud_val(pud) != 0)
-#define pud_page_vaddr(pud) (pud_val(pud) & ~PUD_MASKED_BITS)
+
+static inline pmd_t *pud_pgtable(pud_t pud)
+{
+ return (pmd_t *)(pud_val(pud) & ~PUD_MASKED_BITS);
+}
extern struct page *pud_page(pud_t pud);
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -826,7 +826,7 @@ static void __meminit remove_pud_table(p
continue;
}
- pmd_base = (pmd_t *)pud_page_vaddr(*pud);
+ pmd_base = pud_pgtable(*pud);
remove_pmd_table(pmd_base, addr, next);
free_pmd_table(pmd_base, pud);
}
@@ -1111,7 +1111,7 @@ int pud_free_pmd_page(pud_t *pud, unsign
pmd_t *pmd;
int i;
- pmd = (pmd_t *)pud_page_vaddr(*pud);
+ pmd = pud_pgtable(*pud);
pud_clear(pud);
flush_tlb_kernel_range(addr, addr + PUD_SIZE);
--- a/arch/powerpc/mm/pgtable_64.c~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/powerpc/mm/pgtable_64.c
@@ -115,7 +115,7 @@ struct page *pud_page(pud_t pud)
VM_WARN_ON(!pud_huge(pud));
return pte_page(pud_pte(pud));
}
- return virt_to_page(pud_page_vaddr(pud));
+ return virt_to_page(pud_pgtable(pud));
}
/*
--- a/arch/riscv/include/asm/pgtable-64.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/riscv/include/asm/pgtable-64.h
@@ -59,9 +59,9 @@ static inline void pud_clear(pud_t *pudp
set_pud(pudp, __pud(0));
}
-static inline unsigned long pud_page_vaddr(pud_t pud)
+static inline pmd_t *pud_pgtable(pud_t pud)
{
- return (unsigned long)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT);
+ return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT);
}
static inline struct page *pud_page(pud_t pud)
--- a/arch/sh/include/asm/pgtable-3level.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/sh/include/asm/pgtable-3level.h
@@ -32,9 +32,9 @@ typedef struct { unsigned long long pmd;
#define pmd_val(x) ((x).pmd)
#define __pmd(x) ((pmd_t) { (x) } )
-static inline unsigned long pud_page_vaddr(pud_t pud)
+static inline pmd_t *pud_pgtable(pud_t pud)
{
- return pud_val(pud);
+ return (pmd_t *)pud_val(pud);
}
/* only used by the stubbed out hugetlb gup code, should never be called */
--- a/arch/sparc/include/asm/pgtable_32.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/sparc/include/asm/pgtable_32.h
@@ -151,13 +151,13 @@ static inline unsigned long pmd_page_vad
return (unsigned long)__nocache_va(v << 4);
}
-static inline unsigned long pud_page_vaddr(pud_t pud)
+static inline pmd_t *pud_pgtable(pud_t pud)
{
if (srmmu_device_memory(pud_val(pud))) {
return ~0;
} else {
unsigned long v = pud_val(pud) & SRMMU_PTD_PMASK;
- return (unsigned long)__nocache_va(v << 4);
+ return (pmd_t *)__nocache_va(v << 4);
}
}
--- a/arch/sparc/include/asm/pgtable_64.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/sparc/include/asm/pgtable_64.h
@@ -841,18 +841,18 @@ static inline unsigned long pmd_page_vad
return ((unsigned long) __va(pfn << PAGE_SHIFT));
}
-static inline unsigned long pud_page_vaddr(pud_t pud)
+static inline pmd_t *pud_pgtable(pud_t pud)
{
pte_t pte = __pte(pud_val(pud));
unsigned long pfn;
pfn = pte_pfn(pte);
- return ((unsigned long) __va(pfn << PAGE_SHIFT));
+ return ((pmd_t *) __va(pfn << PAGE_SHIFT));
}
#define pmd_page(pmd) virt_to_page((void *)pmd_page_vaddr(pmd))
-#define pud_page(pud) virt_to_page((void *)pud_page_vaddr(pud))
+#define pud_page(pud) virt_to_page((void *)pud_pgtable(pud))
#define pmd_clear(pmdp) (pmd_val(*(pmdp)) = 0UL)
#define pud_present(pud) (pud_val(pud) != 0U)
#define pud_clear(pudp) (pud_val(*(pudp)) = 0UL)
--- a/arch/um/include/asm/pgtable-3level.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/um/include/asm/pgtable-3level.h
@@ -83,7 +83,7 @@ static inline void pud_clear (pud_t *pud
}
#define pud_page(pud) phys_to_page(pud_val(pud) & PAGE_MASK)
-#define pud_page_vaddr(pud) ((unsigned long) __va(pud_val(pud) & PAGE_MASK))
+#define pud_pgtable(pud) ((pmd_t *) __va(pud_val(pud) & PAGE_MASK))
static inline unsigned long pte_pfn(pte_t pte)
{
--- a/arch/x86/include/asm/pgtable.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/x86/include/asm/pgtable.h
@@ -865,9 +865,9 @@ static inline int pud_present(pud_t pud)
return pud_flags(pud) & _PAGE_PRESENT;
}
-static inline unsigned long pud_page_vaddr(pud_t pud)
+static inline pmd_t *pud_pgtable(pud_t pud)
{
- return (unsigned long)__va(pud_val(pud) & pud_pfn_mask(pud));
+ return (pmd_t *)__va(pud_val(pud) & pud_pfn_mask(pud));
}
/*
--- a/arch/x86/mm/pat/set_memory.c~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/x86/mm/pat/set_memory.c
@@ -1134,7 +1134,7 @@ static void __unmap_pmd_range(pud_t *pud
unsigned long start, unsigned long end)
{
if (unmap_pte_range(pmd, start, end))
- if (try_to_free_pmd_page((pmd_t *)pud_page_vaddr(*pud)))
+ if (try_to_free_pmd_page(pud_pgtable(*pud)))
pud_clear(pud);
}
@@ -1178,7 +1178,7 @@ static void unmap_pmd_range(pud_t *pud,
* Try again to free the PMD page if haven't succeeded above.
*/
if (!pud_none(*pud))
- if (try_to_free_pmd_page((pmd_t *)pud_page_vaddr(*pud)))
+ if (try_to_free_pmd_page(pud_pgtable(*pud)))
pud_clear(pud);
}
--- a/arch/x86/mm/pgtable.c~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/arch/x86/mm/pgtable.c
@@ -801,7 +801,7 @@ int pud_free_pmd_page(pud_t *pud, unsign
pte_t *pte;
int i;
- pmd = (pmd_t *)pud_page_vaddr(*pud);
+ pmd = pud_pgtable(*pud);
pmd_sv = (pmd_t *)__get_free_page(GFP_KERNEL);
if (!pmd_sv)
return 0;
--- a/include/asm-generic/pgtable-nopmd.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/include/asm-generic/pgtable-nopmd.h
@@ -51,7 +51,7 @@ static inline pmd_t * pmd_offset(pud_t *
#define __pmd(x) ((pmd_t) { __pud(x) } )
#define pud_page(pud) (pmd_page((pmd_t){ pud }))
-#define pud_page_vaddr(pud) (pmd_page_vaddr((pmd_t){ pud }))
+#define pud_pgtable(pud) ((pmd_t *)(pmd_page_vaddr((pmd_t){ pud })))
/*
* allocating and freeing a pmd is trivial: the 1-entry pmd is
--- a/include/asm-generic/pgtable-nopud.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/include/asm-generic/pgtable-nopud.h
@@ -49,7 +49,7 @@ static inline pud_t *pud_offset(p4d_t *p
#define __pud(x) ((pud_t) { __p4d(x) })
#define p4d_page(p4d) (pud_page((pud_t){ p4d }))
-#define p4d_page_vaddr(p4d) (pud_page_vaddr((pud_t){ p4d }))
+#define p4d_page_vaddr(p4d) (pud_pgtable((pud_t){ p4d }))
/*
* allocating and freeing a pud is trivial: the 1-entry pud is
--- a/include/linux/pgtable.h~mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t
+++ a/include/linux/pgtable.h
@@ -106,7 +106,7 @@ static inline pte_t *pte_offset_kernel(p
#ifndef pmd_offset
static inline pmd_t *pmd_offset(pud_t *pud, unsigned long address)
{
- return (pmd_t *)pud_page_vaddr(*pud) + pmd_index(address);
+ return pud_pgtable(*pud) + pmd_index(address);
}
#define pmd_offset pmd_offset
#endif
_
Patches currently in -mm which might be from aneesh.kumar@linux.ibm.com are
mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t.patch
mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t.patch
^ permalink raw reply
* Re: [PATCH v10 03/12] swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
From: Konrad Rzeszutek Wilk @ 2021-06-15 22:21 UTC (permalink / raw)
To: Claire Chang
Cc: heikki.krogerus, thomas.hellstrom, peterz, joonas.lahtinen,
dri-devel, chris, grant.likely, paulus, Frank Rowand, mingo,
Marek Szyprowski, sstabellini, Saravana Kannan, Joerg Roedel,
Rafael J . Wysocki, Christoph Hellwig, Bartosz Golaszewski,
bskeggs, linux-pci, xen-devel, Thierry Reding, intel-gfx,
matthew.auld, linux-devicetree, jxgao, daniel, Will Deacon,
maarten.lankhorst, airlied, Dan Williams, linuxppc-dev,
jani.nikula, Rob Herring, rodrigo.vivi, bhelgaas, boris.ostrovsky,
Andy Shevchenko, jgross, Nicolas Boichat, Greg KH, Randy Dunlap,
lkml, tfiga, list@263.net:IOMMU DRIVERS, Jim Quinlan, xypron.glpk,
Robin Murphy, bauerman
In-Reply-To: <20210615132711.553451-4-tientzu@chromium.org>
On Tue, Jun 15, 2021 at 09:27:02PM +0800, Claire Chang wrote:
> Always have the pointer to the swiotlb pool used in struct device. This
> could help simplify the code for other pools.
Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
error: patch failed: kernel/dma/swiotlb.c:339
error: kernel/dma/swiotlb.c: patch does not apply
..
Would you be OK rebasing this against devel/for-linus-5.14 please?
(And please send out with the Reviewed-by from Christopher)
Thank you!
>
> Signed-off-by: Claire Chang <tientzu@chromium.org>
> ---
> drivers/base/core.c | 4 ++++
> include/linux/device.h | 4 ++++
> kernel/dma/swiotlb.c | 8 ++++----
> 3 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index b8a8c96dca58..eeb2d49d3aa3 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -27,6 +27,7 @@
> #include <linux/netdevice.h>
> #include <linux/sched/signal.h>
> #include <linux/sched/mm.h>
> +#include <linux/swiotlb.h>
> #include <linux/sysfs.h>
> #include <linux/dma-map-ops.h> /* for dma_default_coherent */
>
> @@ -2846,6 +2847,9 @@ void device_initialize(struct device *dev)
> defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
> dev->dma_coherent = dma_default_coherent;
> #endif
> +#ifdef CONFIG_SWIOTLB
> + dev->dma_io_tlb_mem = io_tlb_default_mem;
> +#endif
> }
> EXPORT_SYMBOL_GPL(device_initialize);
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 4443e12238a0..2e9a378c9100 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -432,6 +432,7 @@ struct dev_links_info {
> * @dma_pools: Dma pools (if dma'ble device).
> * @dma_mem: Internal for coherent mem override.
> * @cma_area: Contiguous memory area for dma allocations
> + * @dma_io_tlb_mem: Pointer to the swiotlb pool used. Not for driver use.
> * @archdata: For arch-specific additions.
> * @of_node: Associated device tree node.
> * @fwnode: Associated device node supplied by platform firmware.
> @@ -540,6 +541,9 @@ struct device {
> #ifdef CONFIG_DMA_CMA
> struct cma *cma_area; /* contiguous memory area for dma
> allocations */
> +#endif
> +#ifdef CONFIG_SWIOTLB
> + struct io_tlb_mem *dma_io_tlb_mem;
> #endif
> /* arch specific additions */
> struct dev_archdata archdata;
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 97c6ad50fdc2..949a6bb21343 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -339,7 +339,7 @@ void __init swiotlb_exit(void)
> static void swiotlb_bounce(struct device *dev, phys_addr_t tlb_addr, size_t size,
> enum dma_data_direction dir)
> {
> - struct io_tlb_mem *mem = io_tlb_default_mem;
> + struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> int index = (tlb_addr - mem->start) >> IO_TLB_SHIFT;
> phys_addr_t orig_addr = mem->slots[index].orig_addr;
> size_t alloc_size = mem->slots[index].alloc_size;
> @@ -421,7 +421,7 @@ static unsigned int wrap_index(struct io_tlb_mem *mem, unsigned int index)
> static int find_slots(struct device *dev, phys_addr_t orig_addr,
> size_t alloc_size)
> {
> - struct io_tlb_mem *mem = io_tlb_default_mem;
> + struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> unsigned long boundary_mask = dma_get_seg_boundary(dev);
> dma_addr_t tbl_dma_addr =
> phys_to_dma_unencrypted(dev, mem->start) & boundary_mask;
> @@ -498,7 +498,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev, phys_addr_t orig_addr,
> size_t mapping_size, size_t alloc_size,
> enum dma_data_direction dir, unsigned long attrs)
> {
> - struct io_tlb_mem *mem = io_tlb_default_mem;
> + struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> unsigned int offset = swiotlb_align_offset(dev, orig_addr);
> unsigned int i;
> int index;
> @@ -549,7 +549,7 @@ void swiotlb_tbl_unmap_single(struct device *hwdev, phys_addr_t tlb_addr,
> size_t mapping_size, enum dma_data_direction dir,
> unsigned long attrs)
> {
> - struct io_tlb_mem *mem = io_tlb_default_mem;
> + struct io_tlb_mem *mem = hwdev->dma_io_tlb_mem;
> unsigned long flags;
> unsigned int offset = swiotlb_align_offset(hwdev, tlb_addr);
> int index = (tlb_addr - offset - mem->start) >> IO_TLB_SHIFT;
> --
> 2.32.0.272.g935e593368-goog
>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix initrd corruption with relative jump labels
From: Anastasia Kovaleva @ 2021-06-15 13:25 UTC (permalink / raw)
To: Michael Ellerman
Cc: Roman Bolshakov, linuxppc-dev@lists.ozlabs.org, groug@kaod.org,
dja@axtens.net
In-Reply-To: <20210614131440.312360-1-mpe@ellerman.id.au>
> On 14 Jun 2021, at 16:14, Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Commit b0b3b2c78ec0 ("powerpc: Switch to relative jump labels") switched
> us to using relative jump labels. That involves changing the code,
> target and key members in struct jump_entry to be relative to the
> address of the jump_entry, rather than absolute addresses.
>
> We have two static inlines that create a struct jump_entry,
> arch_static_branch() and arch_static_branch_jump(), as well as an asm
> macro ARCH_STATIC_BRANCH, which is used by the pseries-only hypervisor
> tracing code.
>
> Unfortunately we missed updating the key to be a relative reference in
> ARCH_STATIC_BRANCH.
>
> That causes a pseries kernel to have a handful of jump_entry structs
> with bad key values. Instead of being a relative reference they instead
> hold the full address of the key.
>
> However the code doesn't expect that, it still adds the key value to the
> address of the jump_entry (see jump_entry_key()) expecting to get a
> pointer to a key somewhere in kernel data.
>
> The table of jump_entry structs sits in rodata, which comes after the
> kernel text. In a typical build this will be somewhere around 15MB. The
> address of the key will be somewhere in data, typically around 20MB.
> Adding the two values together gets us a pointer somewhere around 45MB.
>
> We then call static_key_set_entries() with that bad pointer and modify
> some members of the struct static_key we think we are pointing at.
>
> A pseries kernel is typically ~30MB in size, so writing to ~45MB won't
> corrupt the kernel itself. However if we're booting with an initrd,
> depending on the size and exact location of the initrd, we can corrupt
> the initrd. Depending on how exactly we corrupt the initrd it can either
> cause the system to not boot, or just corrupt one of the files in the
> initrd.
>
> The fix is simply to make the key value relative to the jump_entry
> struct in the ARCH_STATIC_BRANCH macro.
>
> Fixes: b0b3b2c78ec0 ("powerpc: Switch to relative jump labels")
> Reported-by: Anastasia Kovaleva <a.kovaleva@yadro.com>
> Reported-by: Roman Bolshakov <r.bolshakov@yadro.com>
> Reported-by: Greg Kurz <groug@kaod.org>
> Reported-by: Daniel Axtens <dja@axtens.net>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/include/asm/jump_label.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/jump_label.h b/arch/powerpc/include/asm/jump_label.h
> index 2d5c6bec2b4f..93ce3ec25387 100644
> --- a/arch/powerpc/include/asm/jump_label.h
> +++ b/arch/powerpc/include/asm/jump_label.h
> @@ -50,7 +50,7 @@ static __always_inline bool arch_static_branch_jump(struct static_key *key, bool
> 1098: nop; \
> .pushsection __jump_table, "aw"; \
> .long 1098b - ., LABEL - .; \
> - FTR_ENTRY_LONG KEY; \
> + FTR_ENTRY_LONG KEY - .; \
> .popsection
> #endif
>
> --
> 2.25.1
>
This fixes the issue. Thank you a lot!
Tested-by: Anastasia Kovaleva <a.kovaleva@yadro.com>
Thanks,
Anastasia
^ permalink raw reply
* [powerpc:next-test 119/124] arch/powerpc/kernel/interrupt.c:378:23: warning: no previous prototype for 'syscall_exit_restart'
From: kernel test robot @ 2021-06-15 19:48 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev, kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3347 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: 103bf32b0d2dd8b8a4d3d9ebdded5ba4e8263e6a
commit: 88a293b28ae07acc86b09ebbe8715bcee412a63e [119/124] powerpc/64: use interrupt restart table to speed up return from interrupt
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=88a293b28ae07acc86b09ebbe8715bcee412a63e
git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout 88a293b28ae07acc86b09ebbe8715bcee412a63e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
arch/powerpc/kernel/interrupt.c:246:23: warning: no previous prototype for 'syscall_exit_prepare_main' [-Wmissing-prototypes]
246 | notrace unsigned long syscall_exit_prepare_main(unsigned long r3,
| ^~~~~~~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/kernel/interrupt.c:378:23: warning: no previous prototype for 'syscall_exit_restart' [-Wmissing-prototypes]
378 | notrace unsigned long syscall_exit_restart(unsigned long r3, struct pt_regs *regs)
| ^~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/kernel/interrupt.c:581:23: warning: no previous prototype for 'interrupt_exit_user_restart' [-Wmissing-prototypes]
581 | notrace unsigned long interrupt_exit_user_restart(struct pt_regs *regs)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/kernel/interrupt.c:601:23: warning: no previous prototype for 'interrupt_exit_kernel_restart' [-Wmissing-prototypes]
601 | notrace unsigned long interrupt_exit_kernel_restart(struct pt_regs *regs)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/syscall_exit_restart +378 arch/powerpc/kernel/interrupt.c
376
377 #ifdef CONFIG_PPC64
> 378 notrace unsigned long syscall_exit_restart(unsigned long r3, struct pt_regs *regs)
379 {
380 /*
381 * This is called when detecting a soft-pending interrupt as well as
382 * an alternate-return interrupt. So we can't just have the alternate
383 * return path clear SRR1[MSR] and set PACA_IRQ_HARD_DIS (unless
384 * the soft-pending case were to fix things up as well). RI might be
385 * disabled, in which case it gets re-enabled by __hard_irq_disable().
386 */
387 __hard_irq_disable();
388 local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
389
390 trace_hardirqs_off();
391 user_exit_irqoff();
392 account_cpu_user_entry();
393
394 BUG_ON(!user_mode(regs));
395
396 regs->exit_result |= syscall_exit_prepare_main(r3, regs);
397
398 return regs->exit_result;
399 }
400 #endif
401
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 73399 bytes --]
^ permalink raw reply
* [powerpc:next-test 116/124] arch/powerpc/lib/restart_table.c:13:15: warning: no previous prototype for 'search_kernel_restart_table'
From: kernel test robot @ 2021-06-15 18:42 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev, kbuild-all
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: 103bf32b0d2dd8b8a4d3d9ebdded5ba4e8263e6a
commit: 9d1e5f27172b011ed4d07c92c304fa60caef03ff [116/124] powerpc/64: allow alternate return locations for soft-masked interrupts
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=9d1e5f27172b011ed4d07c92c304fa60caef03ff
git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout 9d1e5f27172b011ed4d07c92c304fa60caef03ff
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> arch/powerpc/lib/restart_table.c:13:15: warning: no previous prototype for 'search_kernel_restart_table' [-Wmissing-prototypes]
13 | unsigned long search_kernel_restart_table(unsigned long addr)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/search_kernel_restart_table +13 arch/powerpc/lib/restart_table.c
11
12 /* Given an address, look for it in the kernel exception table */
> 13 unsigned long search_kernel_restart_table(unsigned long addr)
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 73399 bytes --]
^ permalink raw reply
* Re: [PATCH v19 05/13] of: Add a common kexec FDT setup function
From: Rob Herring @ 2021-06-15 16:34 UTC (permalink / raw)
To: nramas
Cc: Mark Rutland, tao.li, Mimi Zohar, Paul Mackerras,
Vincenzo Frascino, Frank Rowand, Sasha Levin, Stephen Rothwell,
Masahiro Yamada, James Morris, AKASHI Takahiro,
Geert Uytterhoeven, Linux ARM, Catalin Marinas, Serge E. Hallyn,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Pavel Tatashin, Will Deacon, Prakhar Srivastava, Hsin-Yi Wang,
Allison Randal, Christophe Leroy, Matthias Brugger, balajib,
dmitry.kasatkin, Linux Kernel Mailing List, James Morse, Greg KH,
Joe Perches, linux-integrity, linuxppc-dev, Thiago Jung Bauermann
In-Reply-To: <54efb4fce5aac7efbd0b1b3885e9098b1d4ea745.camel@linux.microsoft.com>
On Tue, Jun 15, 2021 at 10:13 AM nramas <nramas@linux.microsoft.com> wrote:
>
> On Tue, 2021-06-15 at 08:01 -0600, Rob Herring wrote:
> > On Tue, Jun 15, 2021 at 6:18 AM Geert Uytterhoeven <
> > geert@linux-m68k.org> wrote:
> > >
> > > > +void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
> > > > + unsigned long
> > > > initrd_load_addr,
> > > > + unsigned long initrd_len,
> > > > + const char *cmdline, size_t
> > > > extra_fdt_size)
> > > > +{
> > > > + /* Did we boot using an initrd? */
> > > > + prop = fdt_getprop(fdt, chosen_node, "linux,initrd-
> > > > start", NULL);
> > > > + if (prop) {
> > > > + u64 tmp_start, tmp_end, tmp_size;
> > > > +
> > > > + tmp_start = fdt64_to_cpu(*((const fdt64_t *)
> > > > prop));
> > > > +
> > > > + prop = fdt_getprop(fdt, chosen_node,
> > > > "linux,initrd-end", NULL);
> > > > + if (!prop) {
> > > > + ret = -EINVAL;
> > > > + goto out;
> > > > + }
> > > > +
> > > > + tmp_end = fdt64_to_cpu(*((const fdt64_t *)
> > > > prop));
> > >
> > > Some kernel code assumes "linux,initrd-{start,end}" are 64-bit,
> > > other code assumes 32-bit.
> >
> > It can be either. The above code was a merge of arm64 and powerpc
> > both
> > of which use 64-bit and still only runs on those arches. It looks
> > like
> > some powerpc platforms may use 32-bit, but this would have been
> > broken
> > before.
> of_kexec_alloc_and_setup_fdt() is called from elf_64.c (in
> arch/powerpc/kexec) which is for 64-bit powerpc platform only.
64-bit PPC could be writing 32-bit property values. The architecture
size doesn't necessarily matter. And if the values came from the
bootloader, who knows what size it used.
This code is 32-bit powerpc only?:
arch/powerpc/boot/main.c- /* Tell the kernel initrd address via
device tree */
arch/powerpc/boot/main.c: setprop_val(chosen,
"linux,initrd-start", (u32)(initrd_addr));
arch/powerpc/boot/main.c- setprop_val(chosen,
"linux,initrd-end", (u32)(initrd_addr+initrd_size));
Rob
^ permalink raw reply
* Re: [PATCH 09/30] mtd_blkdevs: use blk_mq_alloc_disk
From: Marek Szyprowski @ 2021-06-15 16:28 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Justin Sanders, Vignesh Raghavendra, Mike Snitzer,
Michael S. Tsirkin, Jason Wang, virtualization, dm-devel,
Md. Haris Iqbal, Miquel Raynal, Jack Wang, Tim Waugh, linux-s390,
Maxim Levitsky, Richard Weinberger, Bartlomiej Zolnierkiewicz,
Christian Borntraeger, xen-devel, Ilya Dryomov, Vasily Gorbik,
Alex Dubov, Konrad Rzeszutek Wilk, Heiko Carstens, Josef Bacik,
Denis Efremov, nbd, linux-block, ceph-devel, Jens Axboe,
Geoff Levand, linux-mmc, linux-mtd, linuxppc-dev,
Roger Pau Monné
In-Reply-To: <20210615155817.GA31047@lst.de>
Hi Christoph,
On 15.06.2021 17:58, Christoph Hellwig wrote:
> On Tue, Jun 15, 2021 at 05:47:44PM +0200, Marek Szyprowski wrote:
>> On 02.06.2021 08:53, Christoph Hellwig wrote:
>>> Use the blk_mq_alloc_disk API to simplify the gendisk and request_queue
>>> allocation.
>>>
>>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> This patch landed in linux-next as commit 6966bb921def ("mtd_blkdevs:
>> use blk_mq_alloc_disk"). It causes the following regression on my QEMU
>> arm64 setup:
> Please try the patch below:
>
> diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
> index 5dc4c966ea73..6ce4bc57f919 100644
> --- a/drivers/mtd/mtd_blkdevs.c
> +++ b/drivers/mtd/mtd_blkdevs.c
> @@ -382,6 +382,7 @@ int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
> }
>
> new->disk = gd;
> + new->rq = new->disk->queue;
> gd->private_data = new;
> gd->major = tr->major;
> gd->first_minor = (new->devnum) << tr->part_bits;
Right, this fixes the issue, thanks. Feel free to add:
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v19 05/13] of: Add a common kexec FDT setup function
From: nramas @ 2021-06-15 16:13 UTC (permalink / raw)
To: Rob Herring, Geert Uytterhoeven
Cc: Mark Rutland, tao.li, Mimi Zohar, Paul Mackerras,
Vincenzo Frascino, Frank Rowand, Sasha Levin, Stephen Rothwell,
Masahiro Yamada, James Morris, AKASHI Takahiro, Linux ARM,
Catalin Marinas, Serge E. Hallyn,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Pavel Tatashin, Will Deacon, Prakhar Srivastava, Hsin-Yi Wang,
Allison Randal, Christophe Leroy, Matthias Brugger, balajib,
dmitry.kasatkin, Linux Kernel Mailing List, James Morse, Greg KH,
Joe Perches, linux-integrity, linuxppc-dev, Thiago Jung Bauermann
In-Reply-To: <CAL_JsqJ2x7zbyP3fAacdfHOWjCVjg6XhraV2YkoBJdZ2jXAMEA@mail.gmail.com>
On Tue, 2021-06-15 at 08:01 -0600, Rob Herring wrote:
> On Tue, Jun 15, 2021 at 6:18 AM Geert Uytterhoeven <
> geert@linux-m68k.org> wrote:
> >
> > > +void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
> > > + unsigned long
> > > initrd_load_addr,
> > > + unsigned long initrd_len,
> > > + const char *cmdline, size_t
> > > extra_fdt_size)
> > > +{
> > > + /* Did we boot using an initrd? */
> > > + prop = fdt_getprop(fdt, chosen_node, "linux,initrd-
> > > start", NULL);
> > > + if (prop) {
> > > + u64 tmp_start, tmp_end, tmp_size;
> > > +
> > > + tmp_start = fdt64_to_cpu(*((const fdt64_t *)
> > > prop));
> > > +
> > > + prop = fdt_getprop(fdt, chosen_node,
> > > "linux,initrd-end", NULL);
> > > + if (!prop) {
> > > + ret = -EINVAL;
> > > + goto out;
> > > + }
> > > +
> > > + tmp_end = fdt64_to_cpu(*((const fdt64_t *)
> > > prop));
> >
> > Some kernel code assumes "linux,initrd-{start,end}" are 64-bit,
> > other code assumes 32-bit.
>
> It can be either. The above code was a merge of arm64 and powerpc
> both
> of which use 64-bit and still only runs on those arches. It looks
> like
> some powerpc platforms may use 32-bit, but this would have been
> broken
> before.
of_kexec_alloc_and_setup_fdt() is called from elf_64.c (in
arch/powerpc/kexec) which is for 64-bit powerpc platform only.
thanks,
-lakshmi
>
> The code in drivers/of/fdt.c handles either case. We should probably
> refactor early_init_dt_check_for_initrd() and this function to use a
> common routine.
>
> > linux/Documentation/arm/uefi.rst says 64-bit,
> > dt-schema/schemas/chosen.yaml says 32-bit.
>
> We should fix that.
>
> Rob
^ permalink raw reply
* Re: [PATCH 09/30] mtd_blkdevs: use blk_mq_alloc_disk
From: Christoph Hellwig @ 2021-06-15 15:58 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Justin Sanders, Vignesh Raghavendra, Mike Snitzer,
Michael S. Tsirkin, Jason Wang, virtualization, dm-devel,
Md. Haris Iqbal, Miquel Raynal, Jack Wang, Christoph Hellwig,
Tim Waugh, linux-s390, Maxim Levitsky, Richard Weinberger,
Bartlomiej Zolnierkiewicz, Christian Borntraeger, xen-devel,
Ilya Dryomov, Vasily Gorbik, Alex Dubov, Konrad Rzeszutek Wilk,
Heiko Carstens, Josef Bacik, Denis Efremov, nbd, linux-block,
ceph-devel, Jens Axboe, Geoff Levand, linux-mmc, linux-mtd,
linuxppc-dev, Roger Pau Monné
In-Reply-To: <13b21a07-b7c7-37db-fdc9-77bf174b6f8f@samsung.com>
On Tue, Jun 15, 2021 at 05:47:44PM +0200, Marek Szyprowski wrote:
> Hi,
>
> On 02.06.2021 08:53, Christoph Hellwig wrote:
> > Use the blk_mq_alloc_disk API to simplify the gendisk and request_queue
> > allocation.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> This patch landed in linux-next as commit 6966bb921def ("mtd_blkdevs:
> use blk_mq_alloc_disk"). It causes the following regression on my QEMU
> arm64 setup:
Please try the patch below:
diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index 5dc4c966ea73..6ce4bc57f919 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -382,6 +382,7 @@ int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
}
new->disk = gd;
+ new->rq = new->disk->queue;
gd->private_data = new;
gd->major = tr->major;
gd->first_minor = (new->devnum) << tr->part_bits;
^ permalink raw reply related
* Re: [PATCH 09/30] mtd_blkdevs: use blk_mq_alloc_disk
From: Marek Szyprowski @ 2021-06-15 15:47 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe
Cc: Justin Sanders, Vignesh Raghavendra, Mike Snitzer,
Michael S. Tsirkin, Jason Wang, virtualization, dm-devel,
Md. Haris Iqbal, Miquel Raynal, Jack Wang, Tim Waugh, linux-s390,
Alex Dubov, Richard Weinberger, Bartlomiej Zolnierkiewicz,
Christian Borntraeger, xen-devel, Ilya Dryomov, Vasily Gorbik,
Konrad Rzeszutek Wilk, Heiko Carstens, Josef Bacik, Denis Efremov,
nbd, linux-block, ceph-devel, Maxim Levitsky, Geoff Levand,
linux-mmc, linux-mtd, linuxppc-dev, Roger Pau Monné
In-Reply-To: <20210602065345.355274-10-hch@lst.de>
Hi,
On 02.06.2021 08:53, Christoph Hellwig wrote:
> Use the blk_mq_alloc_disk API to simplify the gendisk and request_queue
> allocation.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
This patch landed in linux-next as commit 6966bb921def ("mtd_blkdevs:
use blk_mq_alloc_disk"). It causes the following regression on my QEMU
arm64 setup:
Using buffer write method
Concatenating MTD devices:
(0): "0.flash"
(1): "0.flash"
into device "0.flash"
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000068
Mem abort info:
ESR = 0x96000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
[0000000000000068] user address but active_mm is swapper
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc3+ #10492
Hardware name: linux,dummy-virt (DT)
pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
pc : blk_finish_plug+0x5c/0x268
lr : blk_queue_write_cache+0x28/0x70
...
Call trace:
blk_finish_plug+0x5c/0x268
add_mtd_blktrans_dev+0x270/0x420
mtdblock_add_mtd+0x68/0x98
blktrans_notify_add+0x44/0x70
add_mtd_device+0x41c/0x490
mtd_device_parse_register+0xf4/0x1c8
physmap_flash_probe+0x44c/0x780
platform_probe+0x90/0xd8
really_probe+0x108/0x3c0
driver_probe_device+0x60/0xc0
device_driver_attach+0x6c/0x78
__driver_attach+0xc0/0x100
bus_for_each_dev+0x68/0xc8
driver_attach+0x20/0x28
bus_add_driver+0x168/0x1f8
driver_register+0x60/0x110
__platform_driver_register+0x24/0x30
physmap_init+0x18/0x20
do_one_initcall+0x84/0x450
kernel_init_freeable+0x2dc/0x334
kernel_init+0x10/0x110
ret_from_fork+0x10/0x18
Code: 88027c01 35ffffa2 17fff079 f9800031 (c85f7c22)
---[ end trace b774518e0766cc92 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
SMP: stopping secondary CPUs
Kernel Offset: 0x594d1fa00000 from 0xffff800010000000
PHYS_OFFSET: 0xffffea7300000000
CPU features: 0x11000671,00000846
Memory Limit: none
---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b ]---
> ---
> drivers/mtd/mtd_blkdevs.c | 48 ++++++++++++++++++---------------------
> 1 file changed, 22 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
> index fb8e12d590a1..5dc4c966ea73 100644
> --- a/drivers/mtd/mtd_blkdevs.c
> +++ b/drivers/mtd/mtd_blkdevs.c
> @@ -30,11 +30,9 @@ static void blktrans_dev_release(struct kref *kref)
> struct mtd_blktrans_dev *dev =
> container_of(kref, struct mtd_blktrans_dev, ref);
>
> - dev->disk->private_data = NULL;
> - blk_cleanup_queue(dev->rq);
> + blk_cleanup_disk(dev->disk);
> blk_mq_free_tag_set(dev->tag_set);
> kfree(dev->tag_set);
> - put_disk(dev->disk);
> list_del(&dev->list);
> kfree(dev);
> }
> @@ -354,7 +352,7 @@ int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
> if (new->devnum > (MINORMASK >> tr->part_bits) ||
> (tr->part_bits && new->devnum >= 27 * 26)) {
> mutex_unlock(&blktrans_ref_mutex);
> - goto error1;
> + return ret;
> }
>
> list_add_tail(&new->list, &tr->devs);
> @@ -366,17 +364,28 @@ int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
> if (!tr->writesect)
> new->readonly = 1;
>
> - /* Create gendisk */
> ret = -ENOMEM;
> - gd = alloc_disk(1 << tr->part_bits);
> + new->tag_set = kzalloc(sizeof(*new->tag_set), GFP_KERNEL);
> + if (!new->tag_set)
> + goto out_list_del;
>
> - if (!gd)
> - goto error2;
> + ret = blk_mq_alloc_sq_tag_set(new->tag_set, &mtd_mq_ops, 2,
> + BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_BLOCKING);
> + if (ret)
> + goto out_kfree_tag_set;
> +
> + /* Create gendisk */
> + gd = blk_mq_alloc_disk(new->tag_set, new);
> + if (IS_ERR(gd)) {
> + ret = PTR_ERR(gd);
> + goto out_free_tag_set;
> + }
>
> new->disk = gd;
> gd->private_data = new;
> gd->major = tr->major;
> gd->first_minor = (new->devnum) << tr->part_bits;
> + gd->minors = 1 << tr->part_bits;
> gd->fops = &mtd_block_ops;
>
> if (tr->part_bits)
> @@ -398,22 +407,9 @@ int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
> spin_lock_init(&new->queue_lock);
> INIT_LIST_HEAD(&new->rq_list);
>
> - new->tag_set = kzalloc(sizeof(*new->tag_set), GFP_KERNEL);
> - if (!new->tag_set)
> - goto error3;
> -
> - new->rq = blk_mq_init_sq_queue(new->tag_set, &mtd_mq_ops, 2,
> - BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_BLOCKING);
> - if (IS_ERR(new->rq)) {
> - ret = PTR_ERR(new->rq);
> - new->rq = NULL;
> - goto error4;
> - }
> -
> if (tr->flush)
> blk_queue_write_cache(new->rq, true, false);
>
> - new->rq->queuedata = new;
> blk_queue_logical_block_size(new->rq, tr->blksize);
>
> blk_queue_flag_set(QUEUE_FLAG_NONROT, new->rq);
> @@ -437,13 +433,13 @@ int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
> WARN_ON(ret);
> }
> return 0;
> -error4:
> +
> +out_free_tag_set:
> + blk_mq_free_tag_set(new->tag_set);
> +out_kfree_tag_set:
> kfree(new->tag_set);
> -error3:
> - put_disk(new->disk);
> -error2:
> +out_list_del:
> list_del(&new->list);
> -error1:
> return ret;
> }
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH AUTOSEL 5.10 07/30] ASoC: fsl-asoc-card: Set .owner attribute when registering card.
From: Sasha Levin @ 2021-06-15 15:48 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, alsa-devel, Nicolas Cavallari, Shengjiu Wang,
Mark Brown, linuxppc-dev
In-Reply-To: <20210615154908.62388-1-sashal@kernel.org>
From: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
[ Upstream commit a8437f05384cb472518ec21bf4fffbe8f0a47378 ]
Otherwise, when compiled as module, a WARN_ON is triggered:
WARNING: CPU: 0 PID: 5 at sound/core/init.c:208 snd_card_new+0x310/0x39c [snd]
[...]
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.39 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Workqueue: events deferred_probe_work_func
[<c0111988>] (unwind_backtrace) from [<c010c8ac>] (show_stack+0x10/0x14)
[<c010c8ac>] (show_stack) from [<c092784c>] (dump_stack+0xdc/0x104)
[<c092784c>] (dump_stack) from [<c0129710>] (__warn+0xd8/0x114)
[<c0129710>] (__warn) from [<c0922a48>] (warn_slowpath_fmt+0x5c/0xc4)
[<c0922a48>] (warn_slowpath_fmt) from [<bf0496f8>] (snd_card_new+0x310/0x39c [snd])
[<bf0496f8>] (snd_card_new [snd]) from [<bf1d7df8>] (snd_soc_bind_card+0x334/0x9c4 [snd_soc_core])
[<bf1d7df8>] (snd_soc_bind_card [snd_soc_core]) from [<bf1e9cd8>] (devm_snd_soc_register_card+0x30/0x6c [snd_soc_core])
[<bf1e9cd8>] (devm_snd_soc_register_card [snd_soc_core]) from [<bf22d964>] (fsl_asoc_card_probe+0x550/0xcc8 [snd_soc_fsl_asoc_card])
[<bf22d964>] (fsl_asoc_card_probe [snd_soc_fsl_asoc_card]) from [<c060c930>] (platform_drv_probe+0x48/0x98)
[...]
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Link: https://lore.kernel.org/r/20210527163409.22049-1-nicolas.cavallari@green-communications.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/fsl/fsl-asoc-card.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index a2dd3b6b7fec..7cd14d6b9436 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -720,6 +720,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
/* Initialize sound card */
priv->pdev = pdev;
priv->card.dev = &pdev->dev;
+ priv->card.owner = THIS_MODULE;
ret = snd_soc_of_parse_card_name(&priv->card, "model");
if (ret) {
snprintf(priv->name, sizeof(priv->name), "%s-audio",
--
2.30.2
^ permalink raw reply related
* [PATCH AUTOSEL 5.12 07/33] ASoC: fsl-asoc-card: Set .owner attribute when registering card.
From: Sasha Levin @ 2021-06-15 15:47 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, alsa-devel, Nicolas Cavallari, Shengjiu Wang,
Mark Brown, linuxppc-dev
In-Reply-To: <20210615154824.62044-1-sashal@kernel.org>
From: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
[ Upstream commit a8437f05384cb472518ec21bf4fffbe8f0a47378 ]
Otherwise, when compiled as module, a WARN_ON is triggered:
WARNING: CPU: 0 PID: 5 at sound/core/init.c:208 snd_card_new+0x310/0x39c [snd]
[...]
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.39 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Workqueue: events deferred_probe_work_func
[<c0111988>] (unwind_backtrace) from [<c010c8ac>] (show_stack+0x10/0x14)
[<c010c8ac>] (show_stack) from [<c092784c>] (dump_stack+0xdc/0x104)
[<c092784c>] (dump_stack) from [<c0129710>] (__warn+0xd8/0x114)
[<c0129710>] (__warn) from [<c0922a48>] (warn_slowpath_fmt+0x5c/0xc4)
[<c0922a48>] (warn_slowpath_fmt) from [<bf0496f8>] (snd_card_new+0x310/0x39c [snd])
[<bf0496f8>] (snd_card_new [snd]) from [<bf1d7df8>] (snd_soc_bind_card+0x334/0x9c4 [snd_soc_core])
[<bf1d7df8>] (snd_soc_bind_card [snd_soc_core]) from [<bf1e9cd8>] (devm_snd_soc_register_card+0x30/0x6c [snd_soc_core])
[<bf1e9cd8>] (devm_snd_soc_register_card [snd_soc_core]) from [<bf22d964>] (fsl_asoc_card_probe+0x550/0xcc8 [snd_soc_fsl_asoc_card])
[<bf22d964>] (fsl_asoc_card_probe [snd_soc_fsl_asoc_card]) from [<c060c930>] (platform_drv_probe+0x48/0x98)
[...]
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Link: https://lore.kernel.org/r/20210527163409.22049-1-nicolas.cavallari@green-communications.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/fsl/fsl-asoc-card.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index f62f81ceab0d..9dcbe5d5a428 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -732,6 +732,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
/* Initialize sound card */
priv->pdev = pdev;
priv->card.dev = &pdev->dev;
+ priv->card.owner = THIS_MODULE;
ret = snd_soc_of_parse_card_name(&priv->card, "model");
if (ret) {
snprintf(priv->name, sizeof(priv->name), "%s-audio",
--
2.30.2
^ permalink raw reply related
* Re: [PATCH kernel v2] powerpc/powernv: Reserve a hole which appears after enabling IOV
From: Bjorn Helgaas @ 2021-06-15 15:09 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: linux-pci, Gavin Shan, kvm-ppc, Yongji Xie, Paul Mackerras,
Bjorn Helgaas, linuxppc-dev, David Gibson
In-Reply-To: <20170927065231.20382-1-aik@ozlabs.ru>
On Wed, Sep 27, 2017 at 04:52:31PM +1000, Alexey Kardashevskiy wrote:
> In order to make generic IOV code work, the physical function IOV BAR
> should start from offset of the first VF. Since M64 segments share
> PE number space across PHB, and some PEs may be in use at the time
> when IOV is enabled, the existing code shifts the IOV BAR to the index
> of the first PE/VF. This creates a hole in IOMEM space which can be
> potentially taken by some other device.
>
> This reserves a temporary hole on a parent and releases it when IOV is
> disabled; the temporary resources are stored in pci_dn to avoid
> kmalloc/free.
>
> Cc: linux-pci@vger.kernel.org
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> I assume this goes to powerpc next branch but before this I'd like to
> get Bjorn's opinion as he continously commented on this bit.
>
> This is the diff in /proc/iomem:
>
> @@ -11,6 +11,7 @@
> 200800000000-200bffffffff : 0000:04:00.0
> 210000000000-21fdffffffff : /pciex@3fffe40100000
> 210000000000-21fdfff0ffff : PCI Bus 0001:01
> + 210000000000-210009ffffff : pnv_iov_reserved
> 21000a000000-2101ffffffff : 0001:01:00.0
> 21000a000000-21000bffffff : 0001:01:00.2
> 21000a000000-21000bffffff : mlx5_core
>
> ---
> Changes:
> v2:
> * changed order - now devm_release_resource() is called before
> pci_update_resource(). Strangely the opposite did not produce a warning
> but still
> ---
> arch/powerpc/include/asm/pci-bridge.h | 1 +
> arch/powerpc/platforms/powernv/pci-ioda.c | 24 +++++++++++++++++++++---
> 2 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
> index 0b8aa1fe2d5f..62ed83db04ae 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -218,6 +218,7 @@ struct pci_dn {
> #endif
> struct list_head child_list;
> struct list_head list;
> + struct resource holes[PCI_SRIOV_NUM_BARS];
> };
>
> /* Get the pointer to a device_node's pci_dn */
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 57f9e55f4352..d66a758b8efb 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -1002,9 +1002,12 @@ static int pnv_pci_vf_resource_shift(struct pci_dev *dev, int offset)
> }
>
> /*
> - * After doing so, there would be a "hole" in the /proc/iomem when
> - * offset is a positive value. It looks like the device return some
> - * mmio back to the system, which actually no one could use it.
> + * Since M64 BAR shares segments among all possible 256 PEs,
> + * we have to shift the beginning of PF IOV BAR to make it start from
> + * the segment which belongs to the PE number assigned to the first VF.
> + * This creates a "hole" in the /proc/iomem which could be used for
> + * allocating other resources so we reserve this area below and
> + * release when IOV is released.
> */
> for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
> res = &dev->resource[i + PCI_IOV_RESOURCES];
> @@ -1018,7 +1021,22 @@ static int pnv_pci_vf_resource_shift(struct pci_dev *dev, int offset)
> dev_info(&dev->dev, "VF BAR%d: %pR shifted to %pR (%sabling %d VFs shifted by %d)\n",
> i, &res2, res, (offset > 0) ? "En" : "Dis",
> num_vfs, offset);
> +
> + if (offset < 0) {
> + devm_release_resource(&dev->dev, &pdn->holes[i]);
> + memset(&pdn->holes[i], 0, sizeof(pdn->holes[i]));
> + }
> +
> pci_update_resource(dev, i + PCI_IOV_RESOURCES);
> +
> + if (offset > 0) {
> + pdn->holes[i].start = res2.start;
> + pdn->holes[i].end = res2.start + size * offset - 1;
> + pdn->holes[i].flags = IORESOURCE_BUS;
> + pdn->holes[i].name = "pnv_iov_reserved";
> + devm_request_resource(&dev->dev, res->parent,
> + &pdn->holes[i]);
Does this actually work as you intended? It looks wrong to set
"pdn->holes[i].flags = IORESOURCE_BUS" and then use res->parent,
an IORESOURCE_MEM resource, as the root.
I didn't figure out what actually happens. Maybe nothing, since I
don't see anything in the
devm_request_resource
request_resource_conflict
__request_resource
path that actually *looks* at "flags". But it doesn't look right.
> + }
> }
> return 0;
> }
> --
> 2.11.0
>
^ permalink raw reply
* Oops (NULL pointer) with 'perf record' of selftest 'null_syscall'
From: Christophe Leroy @ 2021-06-15 15:05 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
For your information, I'm getting the following Oops. Detected with 5.13-rc6, it also oopses on 5.12
and 5.11.
Runs ok on 5.10. I'm starting bisecting now.
root@vgoippro:/tmp# perf record /root/null_syscall
[ 285.559987] BUG: Kernel NULL pointer dereference on read at 0x00000040
[ 285.566533] Faulting instruction address: 0xc0021f0c
[ 285.571486] Oops: Kernel access of bad area, sig: 11 [#1]
[ 285.576872] BE PAGE_SIZE=4K PREEMPT CMPCPRO
[ 285.581080] SAF3000 DIE NOTIFICATION
[ 285.584661] CPU: 0 PID: 442 Comm: null_syscall Not tainted 5.13.0-rc6-s3k-dev-01645-g7649ee3d2957
#5164
[ 285.594035] NIP: c0021f0c LR: c00e8ad8 CTR: c00d8a5c
[ 285.599074] REGS: e67757d0 TRAP: 0300 Not tainted (5.13.0-rc6-s3k-dev-01645-g7649ee3d2957)
[ 285.607576] MSR: 00001032 <ME,IR,DR,RI> CR: 44775b18 XER: 20000000
[ 285.614063] DAR: 00000040 DSISR: 20000000
[ 285.614063] GPR00: c00e8810 e6775880 c1c52640 e6775b20 7cb36ae0 f0000028 43ebeedc 5ccc47d0
[ 285.614063] GPR08: 00000000 00000900 e6775b20 00000001 00000000 1025b2c0 10013088 10012ee0
[ 285.614063] GPR16: b0000000 00000007 00000001 c00deb64 00000042 00000001 78db7b23 c0b13200
[ 285.614063] GPR24: 00000000 00000000 00000000 e6775b20 c13b8560 00000107 e6775940 e67758e8
[ 285.651693] NIP [c0021f0c] perf_instruction_pointer+0x10/0x60
[ 285.657460] LR [c00e8ad8] perf_prepare_sample+0x344/0x674
[ 285.662859] Call Trace:
[ 285.665301] [e6775880] [c00e8810] perf_prepare_sample+0x7c/0x674 (unreliable)
[ 285.672452] [e67758c0] [c00e8e44] perf_event_output_forward+0x3c/0x94
[ 285.678903] [e6775910] [c00dea8c] __perf_event_overflow+0x74/0x14c
[ 285.685108] [e6775930] [c00dec5c] perf_swevent_hrtimer+0xf8/0x170
[ 285.691217] [e6775a40] [c008c8d0] __hrtimer_run_queues.constprop.0+0x160/0x318
[ 285.698456] [e6775a90] [c008d94c] hrtimer_interrupt+0x148/0x3b0
[ 285.704394] [e6775ae0] [c000c0c0] timer_interrupt+0xc4/0x22c
[ 285.710067] [e6775b10] [c00046f0] Decrementer_virt+0xb8/0xbc
[ 285.715744] --- interrupt: 900 at pagecache_get_page+0x210/0x430
[ 285.721764] NIP: c00f52a8 LR: c00f5408 CTR: c00f59d8
[ 285.726805] REGS: e6775b20 TRAP: 0900 Not tainted (5.13.0-rc6-s3k-dev-01645-g7649ee3d2957)
[ 285.735306] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28422d68 XER: 00000000
[ 285.742056]
[ 285.742056] GPR00: c00f513c e6775bd0 c1c52640 c1c52640 00000000 00000000 00000000 c1382c38
[ 285.742056] GPR08: 00000000 00000000 00000001 00000000 88482d68 1025b2c0 10013088 10012ee0
[ 285.742056] GPR16: b0000000 00000007 00000001 10012ee0 c18187ac c0b87800 61c88647 c0c18c00
[ 285.742056] GPR24: 00000001 00000003 00000000 00000002 c18187a8 00100cca 00000044 00000000
[ 285.777079] NIP [c00f52a8] pagecache_get_page+0x210/0x430
[ 285.782482] LR [c00f5408] pagecache_get_page+0x370/0x430
[ 285.787796] --- interrupt: 900
[ 285.790843] [e6775bd0] [c00f513c] pagecache_get_page+0xa4/0x430 (unreliable)
[ 285.797910] [e6775c30] [c00f5ca8] filemap_fault+0x2d0/0x8e8
[ 285.803500] [e6775ca0] [c012d244] __do_fault+0x4c/0xd8
[ 285.808666] [e6775cb0] [c0130f64] handle_mm_fault+0x274/0x10b8
[ 285.814517] [e6775d30] [c0014f58] do_page_fault+0x1d4/0x67c
[ 285.820117] [e6775d60] [c000424c] DataAccess_virt+0xd4/0xe4
[ 285.825707] --- interrupt: 300 at __arch_clear_user+0x10/0xcc
[ 285.831458] NIP: c001a3cc LR: c01d5cfc CTR: 00000000
[ 285.836497] REGS: e6775d70 TRAP: 0300 Not tainted (5.13.0-rc6-s3k-dev-01645-g7649ee3d2957)
[ 285.845000] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 48004264 XER: 20000000
[ 285.851751] DAR: 10012ee0 DSISR: 22000000
[ 285.851751] GPR00: c01d53fc e6775e20 c1c52640 00000000 00000120 00000008 c136241c 00000000
[ 285.851751] GPR08: 00000000 9ffed120 10012ee0 00000004 28004868 1025b2c0 10013088 10012ee0
[ 285.851751] GPR16: b0000000 00000007 00000001 10012ee0 10000000 10012d0c 10000000 c1d74240
[ 285.851751] GPR24: 10012ee0 00000000 c1345e80 c1343dc0 10000b38 00000000 c132ec00 c1386a00
[ 285.889384] NIP [c001a3cc] __arch_clear_user+0x10/0xcc
[ 285.894527] LR [c01d5cfc] load_elf_binary+0xec4/0x1340
[ 285.899682] --- interrupt: 300
[ 285.902730] [e6775e20] [c01d53fc] load_elf_binary+0x5c4/0x1340 (unreliable)
[ 285.909713] [e6775ea0] [c0163258] bprm_execve+0x200/0x55c
[ 285.915138] [e6775ef0] [c0163e00] do_execveat_common+0x178/0x1f4
[ 285.921162] [e6775f20] [c0165558] sys_execve+0x40/0x58
[ 285.926321] [e6775f40] [c001404c] ret_from_syscall+0x0/0x28
[ 285.931917] --- interrupt: c00 at 0xfc3ce78
[ 285.936097] NIP: 0fc3ce78 LR: 0fc3d7cc CTR: c01657cc
[ 285.941135] REGS: e6775f50 TRAP: 0c00 Not tainted (5.13.0-rc6-s3k-dev-01645-g7649ee3d2957)
[ 285.949636] MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 22004868 XER: 20000000
[ 285.956655]
[ 285.956655] GPR00: 0000000b afab1bf0 a7d77a50 afab6ee1 afab64c8 104bd9b0 fefefeff 7f7f7f7f
[ 285.956655] GPR08: afab6ee0 00000000 006df8f9 0000011d 24004864 1025b2c0 10231a50 10249108
[ 285.956655] GPR16: 104beeb0 10254830 105dd3f4 10250000 1018a124 10188448 10234e58 00000000
[ 285.956655] GPR24: 10231ae0 00000003 00000001 104bd9b0 afab64c8 afab6ee1 0fd25244 afab1bf0
[ 285.991684] NIP [0fc3ce78] 0xfc3ce78
[ 285.995257] LR [0fc3d7cc] 0xfc3d7cc
[ 285.998742] --- interrupt: c00
[ 286.001789] Instruction dump:
[ 286.004757] 3d20c07d 80a40010 3889847c 486bc444 80630084 546397fe 38630001 4e800020
[ 286.012556] 3d20c0b9 7c6a1b78 810915e4 812300a0 <81080040> 55290036 2c090f00 5508056a
[ 286.020531] ---[ end trace e381e6fcc2db5226 ]---
^ permalink raw reply
* Re: [PATCH v4 1/2] module: add elf_check_module_arch for module specific elf arch checks
From: Segher Boessenkool @ 2021-06-15 14:30 UTC (permalink / raw)
To: Jessica Yu
Cc: Michal Suchánek, linuxppc-dev, linux-kernel, Nicholas Piggin
In-Reply-To: <YMit7PZwiB87ig2u@p200300cbcf109700df096d564fe976c3.dip0.t-ipconnect.de>
On Tue, Jun 15, 2021 at 03:41:00PM +0200, Jessica Yu wrote:
> +++ Segher Boessenkool [15/06/21 07:50 -0500]:
> >On Tue, Jun 15, 2021 at 02:17:40PM +0200, Jessica Yu wrote:
> >>+int __weak elf_check_module_arch(Elf_Ehdr *hdr)
> >>+{
> >>+ return 1;
> >>+}
> >
> >But is this a good idea? It isn't useful to be able to attempt to load
> >a module not compiled for your architecture, and it increases the attack
> >surface tremendously. These checks are one of the few things that can
> >*not* be weak symbols, imo.
>
> Hm, could you please elaborate a bit more? This patchset is adding
> extra Elf header checks specifically for powerpc, and the module
> loader usually provides arch-specific hooks via weak symbols. We are
> just providing an new hook here, which should act as a no-op if it
> isn't used.
>
> So if an architecture wants to provide extra header checks, it can do
> so by overriding the new weak symbol. Otherwise, the weak function acts as
> a noop. We also already have the existing elf_check_arch() check for each
> arch and that is *not* a weak symbol.
The way I read your patch the default elf_check_module_arch does not
call elf_check_arch? Is that clearly called elsewhere and I'm just
dumb again? Sorry for the distraction in that case :-/
Segher
^ permalink raw reply
* Re: [PATCH v3 00/11] powerpc/64: fast interrupt exits
From: Michael Ellerman @ 2021-06-15 14:07 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20210610130921.706938-1-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> This series attempts to improve the speed of interrupts and system calls
> in three major ways.
With the full series applied I'm seeing various warnings.
I feel like I must be missing some lead up patch?
cheers
mambo, p8, hash, be:
[ 0.001038][ T0] ------------[ cut here ]------------
[ 0.001287][ T0] Interrupts were enabled early
[ 0.001510][ T0] WARNING: CPU: 0 PID: 0 at init/main.c:1004 .start_kernel+0x53c/0x720
[ 0.001902][ T0] Modules linked in:
[ 0.002084][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc2-00118-gca433a3a44e3-dirty #1
[ 0.002518][ T0] NIP: c000000002004920 LR: c00000000200491c CTR: c0000000000e3cd0
[ 0.002887][ T0] REGS: c000000002acfc30 TRAP: 0700 Not tainted (5.13.0-rc2-00118-gca433a3a44e3-dirty)
[ 0.003342][ T0] MSR: 9000000002029032 <SF,HV,VEC,EE,ME,IR,DR,RI> CR: 28002222 XER: 22000000
[ 0.003818][ T0] CFAR: 000000003002afb0 IRQMASK: 0
[ 0.003818][ T0] GPR00: c00000000200491c c000000002acfed0 c000000002ad1a00 000000000000001d
[ 0.003818][ T0] GPR04: 0000000000000001 c0000000027645b0 0000000000000001 c0000000027645e0
[ 0.003818][ T0] GPR08: 00000000fd5c0000 c000000002764560 c000000002764560 9000000032001032
[ 0.003818][ T0] GPR12: 0000000028002222 c000000002cd0000 0000000000000000 0000000000000000
[ 0.003818][ T0] GPR16: 0000000031c10000 0000000030003180 0000000030000000 0000000000000000
[ 0.003818][ T0] GPR20: 0000000000000000 0000000000000000 000000003012e4eb 0000000030110ece
[ 0.003818][ T0] GPR24: 00000000301105f5 c000000000000000 0000000020010000 c000000002090008
[ 0.003818][ T0] GPR28: c000000002090008 c0000000011ae620 c0000000011ae620 c000000002090008
[ 0.007455][ T0] NIP [c000000002004920] .start_kernel+0x53c/0x720
[ 0.007765][ T0] LR [c00000000200491c] .start_kernel+0x538/0x720
[ 0.008072][ T0] Call Trace:
[ 0.008223][ T0] [c000000002acfed0] [c00000000200491c] .start_kernel+0x538/0x720 (unreliable)
[ 0.008655][ T0] [c000000002acff90] [c00000000000dd2c] start_here_common+0x1c/0x670
[ 0.009041][ T0] Instruction dump:
[ 0.009219][ T0] 60000000 4a23dadd 60000000 48035821 60000000 892d0932 71290001 40820018
[ 0.009659][ T0] 3c62fe6d 3863f810 4a171751 60000000 <0fe00000> 39200000 3d420003 38600000
[ 0.010111][ T0] ---[ end trace e2dce2fbc72d04fa ]---
mambo, p9, hash, be:
[ 17.668403][ T267] ------------[ cut here ]------------
[ 17.668433][ T267] WARNING: CPU: 1 PID: 267 at arch/powerpc/include/asm/book3s/64/kup.h:304 .arch_local_irq_restore+0x190/0x1a0
[ 17.668503][ T267] Modules linked in:
[ 17.668532][ T267] CPU: 1 PID: 267 Comm: halt Tainted: G W 5.13.0-rc2-00118-gca433a3a44e3-dirty #1
[ 17.668588][ T267] NIP: c000000000016680 LR: c00000000002f804 CTR: c0000000005901c0
[ 17.668632][ T267] REGS: c000000009f339b0 TRAP: 0700 Tainted: G W (5.13.0-rc2-00118-gca433a3a44e3-dirty)
[ 17.668686][ T267] MSR: 9000000000021032 <SF,HV,ME,IR,DR,RI> CR: 48244222 XER: 04000000
[ 17.668777][ T267] CFAR: c00000000002fdcc IRQMASK: 3
[ 17.668777][ T267] GPR00: c00000000002f804 c000000009f33c50 c000000002ad1a00 0000000000000000
[ 17.668777][ T267] GPR04: 0000000000000000 0000000000000020 00000000000000b7 00000000000c9495
[ 17.668777][ T267] GPR08: 0000000000000008 fcffffffffffffff 3cffffffffffffff 0000000000000003
[ 17.668777][ T267] GPR12: 0000000028244228 c0000000fffff300 0000000000000000 0000000000000000
[ 17.668777][ T267] GPR16: 0000000000000000 0000000000000000 0000000000000000 00000000100a0a18
[ 17.668777][ T267] GPR20: 00007fffdf62ffac 00000000100a09d8 00000100011405f0 0000000002002000
[ 17.668777][ T267] GPR24: 0000000000000002 0000000000000001 0000000002802000 0000000000000000
[ 17.668777][ T267] GPR28: c00000000cc56080 0000000000000000 0000000000000000 3cffffffffffffff
[ 17.669291][ T267] NIP [c000000000016680] .arch_local_irq_restore+0x190/0x1a0
[ 17.669343][ T267] LR [c00000000002f804] .interrupt_exit_user_prepare_main+0x144/0x2b0
[ 17.669394][ T267] Call Trace:
[ 17.669418][ T267] [c000000009f33c50] [c000000009f33ce0] 0xc000000009f33ce0 (unreliable)
[ 17.669475][ T267] [c000000009f33cd0] [c00000000002f804] .interrupt_exit_user_prepare_main+0x144/0x2b0
[ 17.669538][ T267] [c000000009f33d90] [c00000000002fe08] .syscall_exit_restart+0x68/0x80
[ 17.669596][ T267] [c000000009f33e10] [c00000000000d168] system_call_common+0x278/0x2dc
[ 17.669652][ T267] --- interrupt: c00 at 0x7fffad5b867c
[ 17.669688][ T267] NIP: 00007fffad5b867c LR: 00000000100992a0 CTR: 0000000000000000
[ 17.669731][ T267] REGS: c000000009f33e80 TRAP: 0c00 Tainted: G W (5.13.0-rc2-00118-gca433a3a44e3-dirty)
[ 17.669785][ T267] MSR: 900000000280f032 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI> CR: 28244222 XER: 00000000
[ 17.669910][ T267] IRQMASK: 0
[ 17.669910][ T267] GPR00: 0000000000000006 00007fffd8758060 00007fffad687300 0000000000000000
[ 17.669910][ T267] GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 17.669910][ T267] GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 17.669910][ T267] GPR12: 0000000000000000 00007fffad70a3a0 0000000000000000 0000000000000000
[ 17.669910][ T267] GPR16: 0000000000000000 0000000000000000 0000000000000000 00000000100a0a18
[ 17.669910][ T267] GPR20: 00007fffdf62ffac 00000000100a09d8 00000100011405f0 00000000100e24d0
[ 17.669910][ T267] GPR24: 00000000100b91e5 00000000100c1e14 0000010019e002a0 00000000100c1e1e
[ 17.669910][ T267] GPR28: 00007fffd875821b 0000000000000004 00007fffd8758210 0000000000000000
[ 17.670410][ T267] NIP [00007fffad5b867c] 0x7fffad5b867c
[ 17.670446][ T267] LR [00000000100992a0] 0x100992a0
[ 17.670480][ T267] --- interrupt: c00
[ 17.670507][ T267] Instruction dump:
[ 17.670535][ T267] 4e800020 60000000 60000000 60000000 39200000 992d0932 39400000 992d0933
[ 17.670627][ T267] 614a8002 7d410164 4e800020 60000000 <0fe00000> 4bfffefc 60000000 60000000
[ 17.670719][ T267] ---[ end trace 5ba1b854b2957ce3 ]---
qemu powernv:
[ 3.446262][ T51] init[51]: segfault (11) at 0 nip 0 lr 1000ca78 code 1 in busybox[10000000+d0000]
[ 3.448351][ T51] init[51]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
[ 3.449598][ T51] init[51]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
[ 3.460559][ T52] init[52]: segfault (11) at 0 nip 0 lr 1000ca78 code 1 in busybox[10000000+d0000]
[ 3.461409][ T52] init[52]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
[ 3.462496][ T52] init[52]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
... to infinity.
qemu 64e gets to running /init but gets stuck there with no further output.
qemu pseries, p8, be:
[ 3.836653][ T75] S20urandom (75) used greatest stack depth: 9792 bytes left
[ 4.718806][ C0] ------------[ cut here ]------------
[ 4.718971][ C0] irq 17 handler .vp_interrupt+0x0/0xc0 enabled interrupts
[ 4.720956][ C0] WARNING: CPU: 0 PID: 99 at kernel/irq/handle.c:159 .__handle_irq_event_percpu+0x230/0x270
[ 4.721113][ C0] Modules linked in:
[ 4.721502][ C0] CPU: 0 PID: 99 Comm: ip Not tainted 5.13.0-rc2-00118-gca433a3a44e3-dirty #1
[ 4.721861][ C0] NIP: c0000000002108b0 LR: c0000000002108ac CTR: c0000000009bb220
[ 4.721943][ C0] REGS: c0000000fffeba00 TRAP: 0700 Not tainted (5.13.0-rc2-00118-gca433a3a44e3-dirty)
[ 4.722081][ C0] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 28002247 XER: 20000000
[ 4.722404][ C0] CFAR: c0000000001760d0 IRQMASK: 0
[ 4.722404][ C0] GPR00: c0000000002108ac c0000000fffebca0 c000000002ad1a00 0000000000000038
[ 4.722404][ C0] GPR04: 0000000000000001 c0000000027645b0 0000000000000027 c0000000ff906e10
[ 4.722404][ C0] GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c0000000011d7b40
[ 4.722404][ C0] GPR12: 0000000028002247 c000000002cd0000 0000000000000000 0000000000000000
[ 4.722404][ C0] GPR16: 0000000000000000 0000000000000000 0000000000000000 00000000100b7866
[ 4.722404][ C0] GPR20: 00000000100b7933 00000000100b5562 0000000000000000 0000000000000001
[ 4.722404][ C0] GPR24: 0000000000000002 0000000000000001 0000000000000011 c000000008891800
[ 4.722404][ C0] GPR28: 0000000000000011 c0000000fffebdd4 c00000000814a880 0000000000000000
[ 4.723412][ C0] NIP [c0000000002108b0] .__handle_irq_event_percpu+0x230/0x270
[ 4.723497][ C0] LR [c0000000002108ac] .__handle_irq_event_percpu+0x22c/0x270
[ 4.723719][ C0] Call Trace:
[ 4.723907][ C0] [c0000000fffebca0] [c0000000002108ac] .__handle_irq_event_percpu+0x22c/0x270 (unreliable)
[ 4.724205][ C0] [c0000000fffebd60] [c000000000210ae0] .handle_irq_event+0x130/0x190
[ 4.724309][ C0] [c0000000fffebe00] [c0000000002182bc] .handle_fasteoi_irq+0xbc/0x310
[ 4.724397][ C0] [c0000000fffebea0] [c00000000020ea74] .generic_handle_irq+0x54/0x80
[ 4.724575][ C0] [c0000000fffebf10] [c000000000015770] .__do_irq+0x70/0x1c0
[ 4.724667][ C0] [c0000000fffebf90] [c0000000000159d4] .do_IRQ+0x114/0x250
[ 4.724764][ C0] [c00000000a0730c0] [c00000000001596c] .do_IRQ+0xac/0x250
[ 4.724848][ C0] [c00000000a073160] [c000000000009230] hardware_interrupt_common_virt+0x1b0/0x1c0
[ 4.724952][ C0] --- interrupt: 500 at .virtnet_send_command+0x138/0x1b0
[ 4.725031][ C0] NIP: c000000000b4db68 LR: c000000000b4db58 CTR: c000000000984910
[ 4.725090][ C0] REGS: c00000000a0731d0 TRAP: 0500 Not tainted (5.13.0-rc2-00118-gca433a3a44e3-dirty)
[ 4.725156][ C0] MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 24002444 XER: 20000000
[ 4.725299][ C0] CFAR: c00000000097e110 IRQMASK: 0
[ 4.725299][ C0] GPR00: c000000000b4db58 c00000000a073470 c000000002ad1a00 0000000000000000
[ 4.725299][ C0] GPR04: c00000000a0734e4 0000000000000000 0000000000000000 0000000000000000
[ 4.725299][ C0] GPR08: 0000000000000000 0000000000000000 0000000000000000 c00c00000002bb48
[ 4.725299][ C0] GPR12: 0000000024002442 c000000002cd0000 0000000000000000 0000000000000000
[ 4.725299][ C0] GPR16: 0000000000000000 0000000000000000 0000000000000000 00000000100b7866
[ 4.725299][ C0] GPR20: 00000000100b7933 00000000100b5562 00000000100b78c8 c000000008d89000
[ 4.725299][ C0] GPR24: 0000000000000003 0000000000001002 c00000000a0734e8 0000000000000002
[ 4.725299][ C0] GPR28: 0000000000000000 0000000000000000 c00000000a073508 c00000000ac41900
[ 4.726021][ C0] NIP [c000000000b4db68] .virtnet_send_command+0x138/0x1b0
[ 4.726091][ C0] LR [c000000000b4db58] .virtnet_send_command+0x128/0x1b0
[ 4.726166][ C0] --- interrupt: 500
[ 4.726226][ C0] [c00000000a073580] [c000000000b4ee2c] .virtnet_set_rx_mode+0xdc/0x3d0
[ 4.726312][ C0] [c00000000a073670] [c000000000d98bac] .__dev_set_rx_mode+0x8c/0x120
[ 4.726397][ C0] [c00000000a073700] [c000000000d98e50] .__dev_open+0x1a0/0x220
[ 4.726477][ C0] [c00000000a0737b0] [c000000000d994ac] .__dev_change_flags+0x23c/0x2e0
[ 4.726557][ C0] [c00000000a073880] [c000000000d99598] .dev_change_flags+0x48/0xa0
[ 4.726639][ C0] [c00000000a073910] [c000000000ec2b18] .devinet_ioctl+0x358/0xa00
[ 4.726729][ C0] [c00000000a0739f0] [c000000000ec5b1c] .inet_ioctl+0x23c/0x340
[ 4.726808][ C0] [c00000000a073b00] [c000000000d52c98] .sock_do_ioctl+0x68/0x1c0
[ 4.726891][ C0] [c00000000a073bd0] [c000000000d55ef4] .sock_ioctl+0x394/0x670
[ 4.726971][ C0] [c00000000a073cc0] [c0000000004d3e2c] .__se_sys_ioctl+0xdc/0x140
[ 4.727081][ C0] [c00000000a073d60] [c00000000002faec] .system_call_exception+0x17c/0x2e0
[ 4.727169][ C0] [c00000000a073e10] [c00000000000cfe4] system_call_common+0xf4/0x2dc
[ 4.727260][ C0] --- interrupt: c00 at 0x7fff7f9bf2f0
[ 4.727630][ C0] NIP: 00007fff7f9bf2f0 LR: 000000001000c6b4 CTR: 0000000000000000
[ 4.727692][ C0] REGS: c00000000a073e80 TRAP: 0c00 Not tainted (5.13.0-rc2-00118-gca433a3a44e3-dirty)
[ 4.727758][ C0] MSR: 800000000280f032 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI> CR: 22000248 XER: 00000000
[ 4.727956][ C0] IRQMASK: 0
[ 4.727956][ C0] GPR00: 0000000000000036 00007ffffba7db00 00007fff7fa87300 0000000000000003
[ 4.727956][ C0] GPR04: 0000000000008914 00007ffffba7dc60 00000000100b554e 0000000000000000
[ 4.727956][ C0] GPR08: 0000000000000003 0000000000000000 0000000000000000 0000000000000000
[ 4.727956][ C0] GPR12: 0000000000000000 00007fff7fb0a3a0 0000000000000000 0000000000000000
[ 4.727956][ C0] GPR16: 0000000000000000 0000000000000000 0000000000000000 00000000100b7866
[ 4.727956][ C0] GPR20: 00000000100b7933 00000000100b5562 00000000100b78c8 0000000000000000
[ 4.727956][ C0] GPR24: 0000000000000000 ffffffffffffffff ffffffffffffffff 0000000000000000
[ 4.727956][ C0] GPR28: 00007ffffba7ff69 0000000000000001 0000000000000003 00000000100b554e
[ 4.728666][ C0] NIP [00007fff7f9bf2f0] 0x7fff7f9bf2f0
[ 4.728719][ C0] LR [000000001000c6b4] 0x1000c6b4
[ 4.728770][ C0] --- interrupt: c00
[ 4.728909][ C0] Instruction dump:
[ 4.729071][ C0] 38636c58 4bffbab9 60000000 4bfffed4 e8be0000 3c62fe70 3d22ffe7 7f44d378
[ 4.729251][ C0] 38636c18 9ae9f062 4bf657c1 60000000 <0fe00000> 9b2d0932 4bfffe70 60000000
[ 4.729494][ C0] ---[ end trace 0d7d391060ba35b4 ]---
qemu-system-ppc64: terminating on signal 1 from pid 462523 (
^ permalink raw reply
* Re: [PATCH v19 05/13] of: Add a common kexec FDT setup function
From: Rob Herring @ 2021-06-15 14:01 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Rutland, tao.li, Mimi Zohar, Paul Mackerras,
Vincenzo Frascino, Frank Rowand, Sasha Levin, Stephen Rothwell,
Lakshmi Ramasubramanian, Masahiro Yamada, James Morris,
AKASHI Takahiro, Linux ARM, Catalin Marinas, Serge E. Hallyn,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Pavel Tatashin, Will Deacon, Prakhar Srivastava, Hsin-Yi Wang,
Allison Randal, Christophe Leroy, Matthias Brugger, balajib,
dmitry.kasatkin, Linux Kernel Mailing List, James Morse, Greg KH,
Joe Perches, linux-integrity, linuxppc-dev, Thiago Jung Bauermann
In-Reply-To: <CAMuHMdVSuNS4edh-zM0_sbC0i1AAjQ9Y0n_8Mjz=3CALkW4pgg@mail.gmail.com>
On Tue, Jun 15, 2021 at 6:18 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Lakshmi and Rob,
>
> On Sun, Feb 21, 2021 at 6:52 PM Lakshmi Ramasubramanian
> <nramas@linux.microsoft.com> wrote:
> > From: Rob Herring <robh@kernel.org>
> >
> > Both arm64 and powerpc do essentially the same FDT /chosen setup for
> > kexec. The differences are either omissions that arm64 should have
> > or additional properties that will be ignored. The setup code can be
> > combined and shared by both powerpc and arm64.
> >
> > The differences relative to the arm64 version:
> > - If /chosen doesn't exist, it will be created (should never happen).
> > - Any old dtb and initrd reserved memory will be released.
> > - The new initrd and elfcorehdr are marked reserved.
> > - "linux,booted-from-kexec" is set.
> >
> > The differences relative to the powerpc version:
> > - "kaslr-seed" and "rng-seed" may be set.
> > - "linux,elfcorehdr" is set.
> > - Any existing "linux,usable-memory-range" is removed.
> >
> > Combine the code for setting up the /chosen node in the FDT and updating
> > the memory reservation for kexec, for powerpc and arm64, in
> > of_kexec_alloc_and_setup_fdt() and move it to "drivers/of/kexec.c".
> >
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
>
> > --- /dev/null
> > +++ b/drivers/of/kexec.c
>
> > +/*
> > + * of_kexec_alloc_and_setup_fdt - Alloc and setup a new Flattened Device Tree
> > + *
> > + * @image: kexec image being loaded.
> > + * @initrd_load_addr: Address where the next initrd will be loaded.
> > + * @initrd_len: Size of the next initrd, or 0 if there will be none.
> > + * @cmdline: Command line for the next kernel, or NULL if there will
> > + * be none.
> > + * @extra_fdt_size: Additional size for the new FDT buffer.
> > + *
> > + * Return: fdt on success, or NULL errno on error.
> > + */
> > +void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
> > + unsigned long initrd_load_addr,
> > + unsigned long initrd_len,
> > + const char *cmdline, size_t extra_fdt_size)
> > +{
>
> > + /* Did we boot using an initrd? */
> > + prop = fdt_getprop(fdt, chosen_node, "linux,initrd-start", NULL);
> > + if (prop) {
> > + u64 tmp_start, tmp_end, tmp_size;
> > +
> > + tmp_start = fdt64_to_cpu(*((const fdt64_t *) prop));
> > +
> > + prop = fdt_getprop(fdt, chosen_node, "linux,initrd-end", NULL);
> > + if (!prop) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
> > +
> > + tmp_end = fdt64_to_cpu(*((const fdt64_t *) prop));
>
> Some kernel code assumes "linux,initrd-{start,end}" are 64-bit,
> other code assumes 32-bit.
It can be either. The above code was a merge of arm64 and powerpc both
of which use 64-bit and still only runs on those arches. It looks like
some powerpc platforms may use 32-bit, but this would have been broken
before.
The code in drivers/of/fdt.c handles either case. We should probably
refactor early_init_dt_check_for_initrd() and this function to use a
common routine.
> linux/Documentation/arm/uefi.rst says 64-bit,
> dt-schema/schemas/chosen.yaml says 32-bit.
We should fix that.
Rob
^ permalink raw reply
* Re: [PATCH v3 11/11] powerpc/64: use interrupt restart table to speed up return from interrupt
From: Michael Ellerman @ 2021-06-15 13:44 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20210610130921.706938-12-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
> index fe26f2fa0f3f..fbe94e2d5011 100644
> --- a/arch/powerpc/lib/feature-fixups.c
> +++ b/arch/powerpc/lib/feature-fixups.c
> @@ -412,12 +430,19 @@ void do_entry_flush_fixups(enum l1d_flush_type types)
> stop_machine(__do_entry_flush_fixups, &types, NULL);
> }
>
> -void do_rfi_flush_fixups(enum l1d_flush_type types)
> +static int __do_rfi_flush_fixups(void *data)
> {
> + enum l1d_flush_type types = *(enum l1d_flush_type *)data;
> unsigned int instrs[3], *dest;
> long *start, *end;
> int i;
>
> + if (types & L1D_FLUSH_FALLBACK)
> + rfi_exit_not_reentrant = true;
> + else
> + rfi_exit_not_reentrant = false;
> + update_interrupt_exit();
This is not happy:
[ 0.000000][ T0] ============================================
[ 0.000000][ T0] WARNING: possible recursive locking detected
[ 0.000000][ T0] 5.13.0-rc2-00118-gca433a3a44e3 #1 Not tainted
[ 0.000000][ T0] --------------------------------------------
[ 0.000000][ T0] swapper/0 is trying to acquire lock:
[ 0.000000][ T0] c00000000252fa10 (cpu_hotplug_lock){....}-{0:0}, at: static_key_enable+0x24/0x50
[ 0.000000][ T0]
[ 0.000000][ T0] but task is already holding lock:
[ 0.000000][ T0] c00000000252fa10 (cpu_hotplug_lock){....}-{0:0}, at: stop_machine+0x2c/0x60
[ 0.000000][ T0]
[ 0.000000][ T0] other info that might help us debug this:
[ 0.000000][ T0] Possible unsafe locking scenario:
[ 0.000000][ T0]
[ 0.000000][ T0] CPU0
[ 0.000000][ T0] ----
[ 0.000000][ T0] lock(cpu_hotplug_lock);
[ 0.000000][ T0] lock(cpu_hotplug_lock);
[ 0.000000][ T0]
[ 0.000000][ T0] *** DEADLOCK ***
[ 0.000000][ T0]
[ 0.000000][ T0] May be due to missing lock nesting notation
[ 0.000000][ T0]
[ 0.000000][ T0] 1 lock held by swapper/0:
[ 0.000000][ T0] #0: c00000000252fa10 (cpu_hotplug_lock){....}-{0:0}, at: stop_machine+0x2c/0x60
[ 0.000000][ T0]
[ 0.000000][ T0] stack backtrace:
[ 0.000000][ T0] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.0-rc2-00118-gca433a3a44e3 #1
[ 0.000000][ T0] Call Trace:
[ 0.000000][ T0] [c0000000027db8f0] [c00000000093dd28] dump_stack+0xec/0x144 (unreliable)
[ 0.000000][ T0] [c0000000027db940] [c0000000001ed5b4] __lock_acquire+0x1744/0x28b0
[ 0.000000][ T0] [c0000000027dba70] [c0000000001ef338] lock_acquire+0x128/0x600
[ 0.000000][ T0] [c0000000027dbb70] [c00000000015035c] cpus_read_lock+0x4c/0x170
[ 0.000000][ T0] [c0000000027dbba0] [c0000000003c2594] static_key_enable+0x24/0x50
[ 0.000000][ T0] [c0000000027dbbd0] [c0000000000ae87c] __do_rfi_flush_fixups+0x7c/0x300
[ 0.000000][ T0] [c0000000027dbc80] [c0000000002ab7e4] stop_machine_cpuslocked+0xe4/0x200
[ 0.000000][ T0] [c0000000027dbcf0] [c0000000002ab940] stop_machine+0x40/0x60
[ 0.000000][ T0] [c0000000027dbd30] [c0000000000aef30] do_rfi_flush_fixups+0x30/0x50
[ 0.000000][ T0] [c0000000027dbd60] [c000000000040890] setup_rfi_flush+0xa0/0x140
[ 0.000000][ T0] [c0000000027dbdd0] [c00000000201c6c4] pnv_setup_arch+0x304/0x4ac
[ 0.000000][ T0] [c0000000027dbe60] [c00000000200a31c] setup_arch+0x374/0x3c4
[ 0.000000][ T0] [c0000000027dbee0] [c000000002003d08] start_kernel+0xb0/0x790
[ 0.000000][ T0] [c0000000027dbf90] [c00000000000d79c] start_here_common+0x1c/0x600
[ 0.000000][ T0] rfi-flush: patched 12 locations (fallback displacement flush)
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox