* Re: Crashes in linux-next on powerpc with CONFIG_PPC_KUAP and CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
From: Michael Ellerman @ 2019-05-09 14:42 UTC (permalink / raw)
To: Petr Mladek; +Cc: linuxppc-dev, linux-kernel, Stephen Rothwell, Linus Torvalds
In-Reply-To: <20190509092942.ei4myfzt5dczuptj@pathway.suse.cz>
Petr Mladek <pmladek@suse.com> writes:
> On Wed 2019-05-08 00:54:51, Michael Ellerman wrote:
>> Hi folks,
>>
>> Just an FYI in case anyone else is seeing crashes very early in boot in
>> linux-next with the above config options.
>>
>> The problem is the combination of some new code called via printk(),
>> check_pointer() which calls probe_kernel_read(). That then calls
>> allow_user_access() (PPC_KUAP) and that uses mmu_has_feature() too early
>> (before we've patched features). With the JUMP_LABEL debug enabled that
>> causes us to call printk() & dump_stack() and we end up recursing and
>> overflowing the stack.
>
> Sigh, the check_pointer() stuff is in Linus's tree now, see
> the commit 3e5903eb9cff707301712 ("vsprintf: Prevent crash when
> dereferencing invalid pointers").
No worries.
>> Because it happens so early you don't get any output, just an apparently
>> dead system.
>>
>> The stack trace (which you don't see) is something like:
>>
>> ...
>> dump_stack+0xdc
>> probe_kernel_read+0x1a4
>> check_pointer+0x58
>> string+0x3c
>> vsnprintf+0x1bc
>> vscnprintf+0x20
>> printk_safe_log_store+0x7c
>> printk+0x40
>> dump_stack_print_info+0xbc
>> dump_stack+0x8
>> probe_kernel_read+0x1a4
>> probe_kernel_read+0x19c
>> check_pointer+0x58
>> string+0x3c
>> vsnprintf+0x1bc
>> vscnprintf+0x20
>> vprintk_store+0x6c
>> vprintk_emit+0xec
>> vprintk_func+0xd4
>> printk+0x40
>> cpufeatures_process_feature+0xc8
>> scan_cpufeatures_subnodes+0x380
>> of_scan_flat_dt_subnodes+0xb4
>> dt_cpu_ftrs_scan_callback+0x158
>> of_scan_flat_dt+0xf0
>> dt_cpu_ftrs_scan+0x3c
>> early_init_devtree+0x360
>> early_setup+0x9c
>>
>>
>> The simple fix is to use early_mmu_has_feature() in allow_user_access(),
>> but we'd rather not do that because it penalises all
>> copy_to/from_users() for the life of the system with the cost of the
>> runtime check vs the jump label. The irony is probe_kernel_read()
>> shouldn't be allowing user access at all, because we're reading the
>> kernel not userspace.
>
> I have tried to find a lightweight way for a safe reading of unknown
> kernel pointer. But I have not succeeded so far. I see only variants
> with user access. The user access is handled in arch-specific code
> and I do not see any variant without it.
>
> I am not sure on which level it should get fixed.
I sent a fix in powerpc code (sorry might have forgot to Cc you):
https://patchwork.ozlabs.org/patch/1097015/
I've merged that into the powerpc tree. I think it's too subtle for us
to have an ordering requirement that deep in the user copy code, it was
just a matter of time before it caused a problem, you were just unlucky
it was your patch that did :)
We'll eventually switch it back to using a jump label but make it safe
to call early in boot before we've detected features.
> Could you please send it to lkml to get a wider audience?
I see you also sent a fix, that looks like a safe default to me.
But as I said I'm happy with the powerpc fix, so there's no requirement
from us that your fix get merged.
cheers
^ permalink raw reply
* Re: Build failure in v4.4.y.queue (ppc:allmodconfig)
From: Michal Suchánek @ 2019-05-09 14:35 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Greg Kroah-Hartman, linuxppc-dev, stable
In-Reply-To: <ace9aeac-f632-c004-1528-8c242def0904@roeck-us.net>
On Thu, 9 May 2019 07:06:32 -0700
Guenter Roeck <linux@roeck-us.net> wrote:
> On 5/9/19 6:26 AM, Michal Suchánek wrote:
> > On Thu, 9 May 2019 06:07:31 -0700
> > Guenter Roeck <linux@roeck-us.net> wrote:
> >
> >> On 5/9/19 2:49 AM, Michal Suchánek wrote:
> >>> On Thu, 9 May 2019 08:53:24 +0200
> >>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >>>
> >>>> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> >>>>> I see multiple instances of:
> >>>>>
> >>>>> arch/powerpc/kernel/exceptions-64s.S:839: Error:
> >>>>> attempt to move .org backwards
> >>>>>
> >>>>> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
> >>>>>
> >>>>> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
> >>>>> forwarding barrier at kernel entry/exit"), which is part of a large patch
> >>>>> series and can not easily be reverted.
> >>>>>
> >>>>> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
> >>>>
> >>>> Michael, I thought this patch series was supposed to fix ppc issues, not
> >>>> add to them :)
> >>>>
> >>>> Any ideas on what to do here?
> >>>
> >>> What exact code do you build?
> >>>
> >> $ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- allmodconfig
> >> $ powerpc64-linux-gcc --version
> >> powerpc64-linux-gcc (GCC) 8.3.0
> >>
> >
> > Gcc should not see this file. I am asking because I do not see an .org
> > directive at line 839 of 4.4.179. I probably need some different repo
> > or extra patches to see the same code as you do.
> >
> v4.4.179-143-gc4db218e9451 from
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> branch linux-4.4.y
Still don't see it. That branch is at 4.4.179 and c4db218e9451 does not
exist after fetching from the repo.
Anyway, here is a patch (untested):
Subject: [PATCH] Move out-of-line exception handlers after relon exception
handlers.
The relon exception handlers need to be at specific location and code
inflation in the common handler code can cause
Error: attempt to move .org backwards
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
arch/powerpc/kernel/exceptions-64s.S | 88 ++++++++++++++--------------
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 938a30fef031..1d477d21ff09 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -772,50 +772,6 @@ kvmppc_skip_Hinterrupt:
b .
#endif
-/*
- * Code from here down to __end_handlers is invoked from the
- * exception prologs above. Because the prologs assemble the
- * addresses of these handlers using the LOAD_HANDLER macro,
- * which uses an ori instruction, these handlers must be in
- * the first 64k of the kernel image.
- */
-
-/*** Common interrupt handlers ***/
-
- STD_EXCEPTION_COMMON(0x100, system_reset, system_reset_exception)
-
- STD_EXCEPTION_COMMON_ASYNC(0x500, hardware_interrupt, do_IRQ)
- STD_EXCEPTION_COMMON_ASYNC(0x900, decrementer, timer_interrupt)
- STD_EXCEPTION_COMMON(0x980, hdecrementer, hdec_interrupt)
-#ifdef CONFIG_PPC_DOORBELL
- STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, doorbell_exception)
-#else
- STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, unknown_exception)
-#endif
- STD_EXCEPTION_COMMON(0xb00, trap_0b, unknown_exception)
- STD_EXCEPTION_COMMON(0xd00, single_step, single_step_exception)
- STD_EXCEPTION_COMMON(0xe00, trap_0e, unknown_exception)
- STD_EXCEPTION_COMMON(0xe40, emulation_assist, emulation_assist_interrupt)
- STD_EXCEPTION_COMMON_ASYNC(0xe60, hmi_exception, handle_hmi_exception)
-#ifdef CONFIG_PPC_DOORBELL
- STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, doorbell_exception)
-#else
- STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, unknown_exception)
-#endif
- STD_EXCEPTION_COMMON_ASYNC(0xf00, performance_monitor, performance_monitor_exception)
- STD_EXCEPTION_COMMON(0x1300, instruction_breakpoint, instruction_breakpoint_exception)
- STD_EXCEPTION_COMMON(0x1502, denorm, unknown_exception)
-#ifdef CONFIG_ALTIVEC
- STD_EXCEPTION_COMMON(0x1700, altivec_assist, altivec_assist_exception)
-#else
- STD_EXCEPTION_COMMON(0x1700, altivec_assist, unknown_exception)
-#endif
-#ifdef CONFIG_CBE_RAS
- STD_EXCEPTION_COMMON(0x1200, cbe_system_error, cbe_system_error_exception)
- STD_EXCEPTION_COMMON(0x1600, cbe_maintenance, cbe_maintenance_exception)
- STD_EXCEPTION_COMMON(0x1800, cbe_thermal, cbe_thermal_exception)
-#endif /* CONFIG_CBE_RAS */
-
/*
* Relocation-on interrupts: A subset of the interrupts can be delivered
* with IR=1/DR=1, if AIL==2 and MSR.HV won't be changed by delivering
@@ -969,6 +925,50 @@ system_call_entry:
ppc64_runlatch_on_trampoline:
b __ppc64_runlatch_on
+/*
+ * Code from here down to __end_handlers is invoked from the
+ * exception prologs above. Because the prologs assemble the
+ * addresses of these handlers using the LOAD_HANDLER macro,
+ * which uses an ori instruction, these handlers must be in
+ * the first 64k of the kernel image.
+ */
+
+/*** Common interrupt handlers ***/
+
+ STD_EXCEPTION_COMMON(0x100, system_reset, system_reset_exception)
+
+ STD_EXCEPTION_COMMON_ASYNC(0x500, hardware_interrupt, do_IRQ)
+ STD_EXCEPTION_COMMON_ASYNC(0x900, decrementer, timer_interrupt)
+ STD_EXCEPTION_COMMON(0x980, hdecrementer, hdec_interrupt)
+#ifdef CONFIG_PPC_DOORBELL
+ STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, doorbell_exception)
+#else
+ STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, unknown_exception)
+#endif
+ STD_EXCEPTION_COMMON(0xb00, trap_0b, unknown_exception)
+ STD_EXCEPTION_COMMON(0xd00, single_step, single_step_exception)
+ STD_EXCEPTION_COMMON(0xe00, trap_0e, unknown_exception)
+ STD_EXCEPTION_COMMON(0xe40, emulation_assist, emulation_assist_interrupt)
+ STD_EXCEPTION_COMMON_ASYNC(0xe60, hmi_exception, handle_hmi_exception)
+#ifdef CONFIG_PPC_DOORBELL
+ STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, doorbell_exception)
+#else
+ STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, unknown_exception)
+#endif
+ STD_EXCEPTION_COMMON_ASYNC(0xf00, performance_monitor, performance_monitor_exception)
+ STD_EXCEPTION_COMMON(0x1300, instruction_breakpoint, instruction_breakpoint_exception)
+ STD_EXCEPTION_COMMON(0x1502, denorm, unknown_exception)
+#ifdef CONFIG_ALTIVEC
+ STD_EXCEPTION_COMMON(0x1700, altivec_assist, altivec_assist_exception)
+#else
+ STD_EXCEPTION_COMMON(0x1700, altivec_assist, unknown_exception)
+#endif
+#ifdef CONFIG_CBE_RAS
+ STD_EXCEPTION_COMMON(0x1200, cbe_system_error, cbe_system_error_exception)
+ STD_EXCEPTION_COMMON(0x1600, cbe_maintenance, cbe_maintenance_exception)
+ STD_EXCEPTION_COMMON(0x1800, cbe_thermal, cbe_thermal_exception)
+#endif /* CONFIG_CBE_RAS */
+
/*
* Here r13 points to the paca, r9 contains the saved CR,
* SRR0 and SRR1 are saved in r11 and r12,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory()
From: Wei Yang @ 2019-05-09 14:31 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-s390, Michal Hocko, linux-ia64, Pavel Tatashin, linux-sh,
mike.travis@hpe.com, Greg Kroah-Hartman, Rafael J. Wysocki,
Mathieu Malaterre, linux-kernel, Ingo Molnar, linux-mm,
Andrew Banman, Qian Cai, Arun KS, akpm, Wei Yang, linuxppc-dev,
Dan Williams, Oscar Salvador
In-Reply-To: <20190507183804.5512-5-david@redhat.com>
On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote:
>Only memory to be added to the buddy and to be onlined/offlined by
>user space using memory block devices needs (and should have!) memory
>block devices.
>
>Factor out creation of memory block devices Create all devices after
>arch_add_memory() succeeded. We can later drop the want_memblock parameter,
>because it is now effectively stale.
>
>Only after memory block devices have been added, memory can be onlined
>by user space. This implies, that memory is not visible to user space at
>all before arch_add_memory() succeeded.
>
>Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>Cc: "Rafael J. Wysocki" <rafael@kernel.org>
>Cc: David Hildenbrand <david@redhat.com>
>Cc: "mike.travis@hpe.com" <mike.travis@hpe.com>
>Cc: Andrew Morton <akpm@linux-foundation.org>
>Cc: Ingo Molnar <mingo@kernel.org>
>Cc: Andrew Banman <andrew.banman@hpe.com>
>Cc: Oscar Salvador <osalvador@suse.de>
>Cc: Michal Hocko <mhocko@suse.com>
>Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
>Cc: Qian Cai <cai@lca.pw>
>Cc: Wei Yang <richard.weiyang@gmail.com>
>Cc: Arun KS <arunks@codeaurora.org>
>Cc: Mathieu Malaterre <malat@debian.org>
>Signed-off-by: David Hildenbrand <david@redhat.com>
>---
> drivers/base/memory.c | 70 ++++++++++++++++++++++++++----------------
> include/linux/memory.h | 2 +-
> mm/memory_hotplug.c | 15 ++++-----
> 3 files changed, 53 insertions(+), 34 deletions(-)
>
>diff --git a/drivers/base/memory.c b/drivers/base/memory.c
>index 6e0cb4fda179..862c202a18ca 100644
>--- a/drivers/base/memory.c
>+++ b/drivers/base/memory.c
>@@ -701,44 +701,62 @@ static int add_memory_block(int base_section_nr)
> return 0;
> }
>
>+static void unregister_memory(struct memory_block *memory)
>+{
>+ BUG_ON(memory->dev.bus != &memory_subsys);
>+
>+ /* drop the ref. we got via find_memory_block() */
>+ put_device(&memory->dev);
>+ device_unregister(&memory->dev);
>+}
>+
> /*
>- * need an interface for the VM to add new memory regions,
>- * but without onlining it.
>+ * Create memory block devices for the given memory area. Start and size
>+ * have to be aligned to memory block granularity. Memory block devices
>+ * will be initialized as offline.
> */
>-int hotplug_memory_register(int nid, struct mem_section *section)
>+int hotplug_memory_register(unsigned long start, unsigned long size)
One trivial suggestion about the function name.
For memory_block device, sometimes we use the full name
find_memory_block
init_memory_block
add_memory_block
But sometimes we use *nick* name
hotplug_memory_register
register_memory
unregister_memory
This is a little bit confusion.
Can we use one name convention here?
[...]
> /*
>@@ -1106,6 +1100,13 @@ int __ref add_memory_resource(int nid, struct resource *res)
> if (ret < 0)
> goto error;
>
>+ /* create memory block devices after memory was added */
>+ ret = hotplug_memory_register(start, size);
>+ if (ret) {
>+ arch_remove_memory(nid, start, size, NULL);
Functionally, it works I think.
But arch_remove_memory() would remove pages from zone. At this point, we just
allocate section/mmap for pages, the zones are empty and pages are not
connected to zone.
Function zone = page_zone(page); always gets zone #0, since pages->flags is 0
at this point. This is not exact.
Would we add some comment to mention this? Or we need to clean up
arch_remove_memory() to take out __remove_zone()?
>+ goto error;
>+ }
>+
> if (new_node) {
> /* If sysfs file of new node can't be created, cpu on the node
> * can't be hot-added. There is no rollback way now.
>--
>2.20.1
--
Wei Yang
Help you, Help me
^ permalink raw reply
* Re: Build failure in v4.4.y.queue (ppc:allmodconfig)
From: Michael Ellerman @ 2019-05-09 14:31 UTC (permalink / raw)
To: Greg Kroah-Hartman, Guenter Roeck; +Cc: linuxppc-dev, stable
In-Reply-To: <20190509065324.GA3864@kroah.com>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
>> I see multiple instances of:
>>
>> arch/powerpc/kernel/exceptions-64s.S:839: Error:
>> attempt to move .org backwards
>>
>> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
>>
>> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
>> forwarding barrier at kernel entry/exit"), which is part of a large patch
>> series and can not easily be reverted.
>>
>> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
>
> Michael, I thought this patch series was supposed to fix ppc issues, not
> add to them :)
Well it fixes some, but creates others :}
> Any ideas on what to do here?
Turning off CONFIG_CBE_RAS (obscure IBM Cell Blade RAS features) is
sufficient to get it building. Is that an option for your build tests
Guenter?
We can try to rearrange some of the exception vectors as Michal
suggested, but that's not without risk either.
cheers
^ permalink raw reply
* Re: Build failure in v4.4.y.queue (ppc:allmodconfig)
From: Guenter Roeck @ 2019-05-09 14:06 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Greg Kroah-Hartman, linuxppc-dev, stable
In-Reply-To: <20190509152649.2e3ef94d@kitsune.suse.cz>
On 5/9/19 6:26 AM, Michal Suchánek wrote:
> On Thu, 9 May 2019 06:07:31 -0700
> Guenter Roeck <linux@roeck-us.net> wrote:
>
>> On 5/9/19 2:49 AM, Michal Suchánek wrote:
>>> On Thu, 9 May 2019 08:53:24 +0200
>>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>>>
>>>> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
>>>>> I see multiple instances of:
>>>>>
>>>>> arch/powerpc/kernel/exceptions-64s.S:839: Error:
>>>>> attempt to move .org backwards
>>>>>
>>>>> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
>>>>>
>>>>> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
>>>>> forwarding barrier at kernel entry/exit"), which is part of a large patch
>>>>> series and can not easily be reverted.
>>>>>
>>>>> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
>>>>
>>>> Michael, I thought this patch series was supposed to fix ppc issues, not
>>>> add to them :)
>>>>
>>>> Any ideas on what to do here?
>>>
>>> What exact code do you build?
>>>
>> $ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- allmodconfig
>> $ powerpc64-linux-gcc --version
>> powerpc64-linux-gcc (GCC) 8.3.0
>>
>
> Gcc should not see this file. I am asking because I do not see an .org
> directive at line 839 of 4.4.179. I probably need some different repo
> or extra patches to see the same code as you do.
>
v4.4.179-143-gc4db218e9451 from
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
branch linux-4.4.y
That also includes 'powerpc/64s: Improve RFI L1-D cache flush fallback',
but reverting it does not make a difference. Also, the .org is
hidden in STD_RELON_EXCEPTION_PSERIES().
Guenter
^ permalink raw reply
* Re: [PATCH] vsprintf: Do not break early boot with probing addresses
From: Petr Mladek @ 2019-05-09 14:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-arch, Sergey Senozhatsky, Heiko Carstens, linux-s390,
linuxppc-dev, Rasmus Villemoes, linux-kernel, Michal Hocko,
Sergey Senozhatsky, Stephen Rothwell, Andy Shevchenko,
Linus Torvalds, Martin Schwidefsky, Tobin C . Harding
In-Reply-To: <20190509091357.0af3fcd7@gandalf.local.home>
On Thu 2019-05-09 09:13:57, Steven Rostedt wrote:
> On Thu, 9 May 2019 14:19:23 +0200
> Petr Mladek <pmladek@suse.com> wrote:
>
> > The commit 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing
> > invalid pointers") broke boot on several architectures. The common
> > pattern is that probe_kernel_read() is not working during early
> > boot because userspace access framework is not ready.
> >
> > The check is only the best effort. Let's not rush with it during
> > the early boot.
> >
> > Details:
> >
> > 1. Report on Power:
> >
> > Kernel crashes very early during boot with with CONFIG_PPC_KUAP and
> > CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
> >
> > The problem is the combination of some new code called via printk(),
> > check_pointer() which calls probe_kernel_read(). That then calls
> > allow_user_access() (PPC_KUAP) and that uses mmu_has_feature() too early
> > (before we've patched features). With the JUMP_LABEL debug enabled that
> > causes us to call printk() & dump_stack() and we end up recursing and
> > overflowing the stack.
> >
> > Because it happens so early you don't get any output, just an apparently
> > dead system.
> >
> > The stack trace (which you don't see) is something like:
> >
> > ...
> > dump_stack+0xdc
> > probe_kernel_read+0x1a4
> > check_pointer+0x58
> > string+0x3c
> > vsnprintf+0x1bc
> > vscnprintf+0x20
> > printk_safe_log_store+0x7c
> > printk+0x40
> > dump_stack_print_info+0xbc
> > dump_stack+0x8
> > probe_kernel_read+0x1a4
> > probe_kernel_read+0x19c
> > check_pointer+0x58
> > string+0x3c
> > vsnprintf+0x1bc
> > vscnprintf+0x20
> > vprintk_store+0x6c
> > vprintk_emit+0xec
> > vprintk_func+0xd4
> > printk+0x40
> > cpufeatures_process_feature+0xc8
> > scan_cpufeatures_subnodes+0x380
> > of_scan_flat_dt_subnodes+0xb4
> > dt_cpu_ftrs_scan_callback+0x158
> > of_scan_flat_dt+0xf0
> > dt_cpu_ftrs_scan+0x3c
> > early_init_devtree+0x360
> > early_setup+0x9c
> >
> > 2. Report on s390:
> >
> > vsnprintf invocations, are broken on s390. For example, the early boot
> > output now looks like this where the first (efault) should be
> > the linux_banner:
> >
> > [ 0.099985] (efault)
> > [ 0.099985] setup: Linux is running as a z/VM guest operating system in 64-bit mode
> > [ 0.100066] setup: The maximum memory size is 8192MB
> > [ 0.100070] cma: Reserved 4 MiB at (efault)
> > [ 0.100100] numa: NUMA mode: (efault)
> >
> > The reason for this, is that the code assumes that
> > probe_kernel_address() works very early. This however is not true on
> > at least s390. Uaccess on KERNEL_DS works only after page tables have
> > been setup on s390, which happens with setup_arch()->paging_init().
> >
> > Any probe_kernel_address() invocation before that will return -EFAULT.
>
> Hmm, this sounds to me that probe_kernel_address() is broken for these
> architectures. Perhaps the system_state check should be in
> probe_kernel_address() for those architectures?
Yeah. Well, these problems are hard to debug. It left a dead power
system with a blank screen. I am not sure if the added check is
worth the pain.
I hope that the check would help to debug problems. But it is yet
another complexity in printk() path. I think that it is fine
to keep it enabled only on the booted system for a while
and get some more feedback.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory()
From: David Hildenbrand @ 2019-05-09 14:05 UTC (permalink / raw)
To: Wei Yang
Cc: linux-s390, Michal Hocko, linux-ia64, Pavel Tatashin, linux-sh,
mike.travis@hpe.com, Greg Kroah-Hartman, Rafael J. Wysocki,
Mathieu Malaterre, linux-kernel, Ingo Molnar, linux-mm,
Andrew Banman, Qian Cai, Arun KS, akpm, linuxppc-dev,
Dan Williams, Oscar Salvador
In-Reply-To: <20190509135533.6xok3v7rxxaohc77@master>
On 09.05.19 15:55, Wei Yang wrote:
> On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote:
>> Only memory to be added to the buddy and to be onlined/offlined by
>> user space using memory block devices needs (and should have!) memory
>> block devices.
>>
>> Factor out creation of memory block devices Create all devices after
>> arch_add_memory() succeeded. We can later drop the want_memblock parameter,
>> because it is now effectively stale.
>>
>> Only after memory block devices have been added, memory can be onlined
>> by user space. This implies, that memory is not visible to user space at
>> all before arch_add_memory() succeeded.
>>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
>> Cc: David Hildenbrand <david@redhat.com>
>> Cc: "mike.travis@hpe.com" <mike.travis@hpe.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Ingo Molnar <mingo@kernel.org>
>> Cc: Andrew Banman <andrew.banman@hpe.com>
>> Cc: Oscar Salvador <osalvador@suse.de>
>> Cc: Michal Hocko <mhocko@suse.com>
>> Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
>> Cc: Qian Cai <cai@lca.pw>
>> Cc: Wei Yang <richard.weiyang@gmail.com>
>> Cc: Arun KS <arunks@codeaurora.org>
>> Cc: Mathieu Malaterre <malat@debian.org>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>> drivers/base/memory.c | 70 ++++++++++++++++++++++++++----------------
>> include/linux/memory.h | 2 +-
>> mm/memory_hotplug.c | 15 ++++-----
>> 3 files changed, 53 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
>> index 6e0cb4fda179..862c202a18ca 100644
>> --- a/drivers/base/memory.c
>> +++ b/drivers/base/memory.c
>> @@ -701,44 +701,62 @@ static int add_memory_block(int base_section_nr)
>> return 0;
>> }
>>
>> +static void unregister_memory(struct memory_block *memory)
>> +{
>> + BUG_ON(memory->dev.bus != &memory_subsys);
>> +
>> + /* drop the ref. we got via find_memory_block() */
>> + put_device(&memory->dev);
>> + device_unregister(&memory->dev);
>> +}
>> +
>> /*
>> - * need an interface for the VM to add new memory regions,
>> - * but without onlining it.
>> + * Create memory block devices for the given memory area. Start and size
>> + * have to be aligned to memory block granularity. Memory block devices
>> + * will be initialized as offline.
>> */
>> -int hotplug_memory_register(int nid, struct mem_section *section)
>> +int hotplug_memory_register(unsigned long start, unsigned long size)
>> {
>> - int ret = 0;
>> + unsigned long block_nr_pages = memory_block_size_bytes() >> PAGE_SHIFT;
>> + unsigned long start_pfn = PFN_DOWN(start);
>> + unsigned long end_pfn = start_pfn + (size >> PAGE_SHIFT);
>> + unsigned long pfn;
>> struct memory_block *mem;
>> + int ret = 0;
>>
>> - mutex_lock(&mem_sysfs_mutex);
>> + BUG_ON(!IS_ALIGNED(start, memory_block_size_bytes()));
>> + BUG_ON(!IS_ALIGNED(size, memory_block_size_bytes()));
>>
>> - mem = find_memory_block(section);
>> - if (mem) {
>> - mem->section_count++;
>> - put_device(&mem->dev);
>> - } else {
>> - ret = init_memory_block(&mem, section, MEM_OFFLINE);
>> + mutex_lock(&mem_sysfs_mutex);
>> + for (pfn = start_pfn; pfn != end_pfn; pfn += block_nr_pages) {
>> + mem = find_memory_block(__pfn_to_section(pfn));
>> + if (mem) {
>> + WARN_ON_ONCE(false);
>
> One question here, the purpose of WARN_ON_ONCE(false) is? Would we trigger
> this?
Would happen if something goes terribly wrong. We might want to remove
this once we are sure this will not happen.
I replaced it in the meantime by a
if (WARN_ON_ONCE(mem)) {
put_device(&mem->dev);
ret = -EEXIST;
break;
}
>
>> + put_device(&mem->dev);
>> + continue;
>> + }
>> + ret = init_memory_block(&mem, __pfn_to_section(pfn),
>> + MEM_OFFLINE);
>> if (ret)
>> - goto out;
>> - mem->section_count++;
>> + break;
>> + mem->section_count = memory_block_size_bytes() /
>> + MIN_MEMORY_BLOCK_SIZE;
>
> Maybe we can leverage sections_per_block variable.
Most certainly if it does what I think it does :) thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory()
From: Wei Yang @ 2019-05-09 13:55 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-s390, Michal Hocko, linux-ia64, Pavel Tatashin, linux-sh,
mike.travis@hpe.com, Greg Kroah-Hartman, Rafael J. Wysocki,
Mathieu Malaterre, linux-kernel, Ingo Molnar, linux-mm,
Andrew Banman, Qian Cai, Arun KS, akpm, Wei Yang, linuxppc-dev,
Dan Williams, Oscar Salvador
In-Reply-To: <20190507183804.5512-5-david@redhat.com>
On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote:
>Only memory to be added to the buddy and to be onlined/offlined by
>user space using memory block devices needs (and should have!) memory
>block devices.
>
>Factor out creation of memory block devices Create all devices after
>arch_add_memory() succeeded. We can later drop the want_memblock parameter,
>because it is now effectively stale.
>
>Only after memory block devices have been added, memory can be onlined
>by user space. This implies, that memory is not visible to user space at
>all before arch_add_memory() succeeded.
>
>Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>Cc: "Rafael J. Wysocki" <rafael@kernel.org>
>Cc: David Hildenbrand <david@redhat.com>
>Cc: "mike.travis@hpe.com" <mike.travis@hpe.com>
>Cc: Andrew Morton <akpm@linux-foundation.org>
>Cc: Ingo Molnar <mingo@kernel.org>
>Cc: Andrew Banman <andrew.banman@hpe.com>
>Cc: Oscar Salvador <osalvador@suse.de>
>Cc: Michal Hocko <mhocko@suse.com>
>Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
>Cc: Qian Cai <cai@lca.pw>
>Cc: Wei Yang <richard.weiyang@gmail.com>
>Cc: Arun KS <arunks@codeaurora.org>
>Cc: Mathieu Malaterre <malat@debian.org>
>Signed-off-by: David Hildenbrand <david@redhat.com>
>---
> drivers/base/memory.c | 70 ++++++++++++++++++++++++++----------------
> include/linux/memory.h | 2 +-
> mm/memory_hotplug.c | 15 ++++-----
> 3 files changed, 53 insertions(+), 34 deletions(-)
>
>diff --git a/drivers/base/memory.c b/drivers/base/memory.c
>index 6e0cb4fda179..862c202a18ca 100644
>--- a/drivers/base/memory.c
>+++ b/drivers/base/memory.c
>@@ -701,44 +701,62 @@ static int add_memory_block(int base_section_nr)
> return 0;
> }
>
>+static void unregister_memory(struct memory_block *memory)
>+{
>+ BUG_ON(memory->dev.bus != &memory_subsys);
>+
>+ /* drop the ref. we got via find_memory_block() */
>+ put_device(&memory->dev);
>+ device_unregister(&memory->dev);
>+}
>+
> /*
>- * need an interface for the VM to add new memory regions,
>- * but without onlining it.
>+ * Create memory block devices for the given memory area. Start and size
>+ * have to be aligned to memory block granularity. Memory block devices
>+ * will be initialized as offline.
> */
>-int hotplug_memory_register(int nid, struct mem_section *section)
>+int hotplug_memory_register(unsigned long start, unsigned long size)
> {
>- int ret = 0;
>+ unsigned long block_nr_pages = memory_block_size_bytes() >> PAGE_SHIFT;
>+ unsigned long start_pfn = PFN_DOWN(start);
>+ unsigned long end_pfn = start_pfn + (size >> PAGE_SHIFT);
>+ unsigned long pfn;
> struct memory_block *mem;
>+ int ret = 0;
>
>- mutex_lock(&mem_sysfs_mutex);
>+ BUG_ON(!IS_ALIGNED(start, memory_block_size_bytes()));
>+ BUG_ON(!IS_ALIGNED(size, memory_block_size_bytes()));
>
>- mem = find_memory_block(section);
>- if (mem) {
>- mem->section_count++;
>- put_device(&mem->dev);
>- } else {
>- ret = init_memory_block(&mem, section, MEM_OFFLINE);
>+ mutex_lock(&mem_sysfs_mutex);
>+ for (pfn = start_pfn; pfn != end_pfn; pfn += block_nr_pages) {
>+ mem = find_memory_block(__pfn_to_section(pfn));
>+ if (mem) {
>+ WARN_ON_ONCE(false);
One question here, the purpose of WARN_ON_ONCE(false) is? Would we trigger
this?
>+ put_device(&mem->dev);
>+ continue;
>+ }
>+ ret = init_memory_block(&mem, __pfn_to_section(pfn),
>+ MEM_OFFLINE);
> if (ret)
>- goto out;
>- mem->section_count++;
>+ break;
>+ mem->section_count = memory_block_size_bytes() /
>+ MIN_MEMORY_BLOCK_SIZE;
Maybe we can leverage sections_per_block variable.
mem->section_count = sections_per_block;
>+ }
>+ if (ret) {
>+ end_pfn = pfn;
>+ for (pfn = start_pfn; pfn != end_pfn; pfn += block_nr_pages) {
>+ mem = find_memory_block(__pfn_to_section(pfn));
>+ if (!mem)
>+ continue;
>+ mem->section_count = 0;
>+ unregister_memory(mem);
>+ }
> }
--
Wei Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH] vsprintf: Do not break early boot with probing addresses
From: Michal Suchánek @ 2019-05-09 13:38 UTC (permalink / raw)
To: Petr Mladek
Cc: linux-arch, linux-s390, Sergey Senozhatsky, Rasmus Villemoes,
linuxppc-dev, Heiko Carstens, linux-kernel, Steven Rostedt,
Michal Hocko, Sergey Senozhatsky, Stephen Rothwell,
Andy Shevchenko, Linus Torvalds, Martin Schwidefsky,
Tobin C . Harding
In-Reply-To: <20190509121923.8339-1-pmladek@suse.com>
On Thu, 9 May 2019 14:19:23 +0200
Petr Mladek <pmladek@suse.com> wrote:
> The commit 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing
> invalid pointers") broke boot on several architectures. The common
> pattern is that probe_kernel_read() is not working during early
> boot because userspace access framework is not ready.
>
> The check is only the best effort. Let's not rush with it during
> the early boot.
>
> Details:
>
> 1. Report on Power:
>
> Kernel crashes very early during boot with with CONFIG_PPC_KUAP and
> CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
>
> The problem is the combination of some new code called via printk(),
> check_pointer() which calls probe_kernel_read(). That then calls
> allow_user_access() (PPC_KUAP) and that uses mmu_has_feature() too early
> (before we've patched features).
There is early_mmu_has_feature for this case. mmu_has_feature does not
work before patching so parts of kernel that can run before patching
must use the early_ variant which actually runs code reading the
feature bitmap to determine the answer.
Thanks
Michal
^ permalink raw reply
* Re: Build failure in v4.4.y.queue (ppc:allmodconfig)
From: Michal Suchánek @ 2019-05-09 13:26 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Greg Kroah-Hartman, linuxppc-dev, stable
In-Reply-To: <e8aa590e-a02f-19de-96df-6728ded7aab3@roeck-us.net>
On Thu, 9 May 2019 06:07:31 -0700
Guenter Roeck <linux@roeck-us.net> wrote:
> On 5/9/19 2:49 AM, Michal Suchánek wrote:
> > On Thu, 9 May 2019 08:53:24 +0200
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >
> >> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> >>> I see multiple instances of:
> >>>
> >>> arch/powerpc/kernel/exceptions-64s.S:839: Error:
> >>> attempt to move .org backwards
> >>>
> >>> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
> >>>
> >>> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
> >>> forwarding barrier at kernel entry/exit"), which is part of a large patch
> >>> series and can not easily be reverted.
> >>>
> >>> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
> >>
> >> Michael, I thought this patch series was supposed to fix ppc issues, not
> >> add to them :)
> >>
> >> Any ideas on what to do here?
> >
> > What exact code do you build?
> >
> $ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- allmodconfig
> $ powerpc64-linux-gcc --version
> powerpc64-linux-gcc (GCC) 8.3.0
>
Gcc should not see this file. I am asking because I do not see an .org
directive at line 839 of 4.4.179. I probably need some different repo
or extra patches to see the same code as you do.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH] vsprintf: Do not break early boot with probing addresses
From: Steven Rostedt @ 2019-05-09 13:13 UTC (permalink / raw)
To: Petr Mladek
Cc: linux-arch, Sergey Senozhatsky, Heiko Carstens, linux-s390,
linuxppc-dev, Rasmus Villemoes, linux-kernel, Michal Hocko,
Sergey Senozhatsky, Stephen Rothwell, Andy Shevchenko,
Linus Torvalds, Martin Schwidefsky, Tobin C . Harding
In-Reply-To: <20190509121923.8339-1-pmladek@suse.com>
On Thu, 9 May 2019 14:19:23 +0200
Petr Mladek <pmladek@suse.com> wrote:
> The commit 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing
> invalid pointers") broke boot on several architectures. The common
> pattern is that probe_kernel_read() is not working during early
> boot because userspace access framework is not ready.
>
> The check is only the best effort. Let's not rush with it during
> the early boot.
>
> Details:
>
> 1. Report on Power:
>
> Kernel crashes very early during boot with with CONFIG_PPC_KUAP and
> CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
>
> The problem is the combination of some new code called via printk(),
> check_pointer() which calls probe_kernel_read(). That then calls
> allow_user_access() (PPC_KUAP) and that uses mmu_has_feature() too early
> (before we've patched features). With the JUMP_LABEL debug enabled that
> causes us to call printk() & dump_stack() and we end up recursing and
> overflowing the stack.
>
> Because it happens so early you don't get any output, just an apparently
> dead system.
>
> The stack trace (which you don't see) is something like:
>
> ...
> dump_stack+0xdc
> probe_kernel_read+0x1a4
> check_pointer+0x58
> string+0x3c
> vsnprintf+0x1bc
> vscnprintf+0x20
> printk_safe_log_store+0x7c
> printk+0x40
> dump_stack_print_info+0xbc
> dump_stack+0x8
> probe_kernel_read+0x1a4
> probe_kernel_read+0x19c
> check_pointer+0x58
> string+0x3c
> vsnprintf+0x1bc
> vscnprintf+0x20
> vprintk_store+0x6c
> vprintk_emit+0xec
> vprintk_func+0xd4
> printk+0x40
> cpufeatures_process_feature+0xc8
> scan_cpufeatures_subnodes+0x380
> of_scan_flat_dt_subnodes+0xb4
> dt_cpu_ftrs_scan_callback+0x158
> of_scan_flat_dt+0xf0
> dt_cpu_ftrs_scan+0x3c
> early_init_devtree+0x360
> early_setup+0x9c
>
> 2. Report on s390:
>
> vsnprintf invocations, are broken on s390. For example, the early boot
> output now looks like this where the first (efault) should be
> the linux_banner:
>
> [ 0.099985] (efault)
> [ 0.099985] setup: Linux is running as a z/VM guest operating system in 64-bit mode
> [ 0.100066] setup: The maximum memory size is 8192MB
> [ 0.100070] cma: Reserved 4 MiB at (efault)
> [ 0.100100] numa: NUMA mode: (efault)
>
> The reason for this, is that the code assumes that
> probe_kernel_address() works very early. This however is not true on
> at least s390. Uaccess on KERNEL_DS works only after page tables have
> been setup on s390, which happens with setup_arch()->paging_init().
>
> Any probe_kernel_address() invocation before that will return -EFAULT.
Hmm, this sounds to me that probe_kernel_address() is broken for these
architectures. Perhaps the system_state check should be in
probe_kernel_address() for those architectures?
>
> Fixes: 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing invalid pointers")
> Signed-off-by: Petr Mladek <pmladek@suse.com>
> ---
> lib/vsprintf.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 7b0a6140bfad..8b43a883be6b 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -640,8 +640,13 @@ static const char *check_pointer_msg(const void *ptr)
> if (!ptr)
> return "(null)";
>
> - if (probe_kernel_address(ptr, byte))
> - return "(efault)";
Either that, or we add a macro to those architectures and add:
#ifdef ARCH_NO_EARLY_PROBE_KERNEL_ADDRESS
> + /* User space address handling is not ready during early boot. */
> + if (system_state <= SYSTEM_BOOTING) {
> + if ((unsigned long)ptr < PAGE_SIZE)
> + return "(efault)";
> + } else {
#endif
Why add an unnecessary branch for archs this is not a problem for?
-- Steve
> + if (probe_kernel_address(ptr, byte))
> + return "(efault)";
>
> return NULL;
> }
^ permalink raw reply
* Re: Build failure in v4.4.y.queue (ppc:allmodconfig)
From: Guenter Roeck @ 2019-05-09 13:07 UTC (permalink / raw)
To: Michal Suchánek, Greg Kroah-Hartman; +Cc: linuxppc-dev, stable
In-Reply-To: <20190509114923.696222cb@naga>
On 5/9/19 2:49 AM, Michal Suchánek wrote:
> On Thu, 9 May 2019 08:53:24 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
>> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
>>> I see multiple instances of:
>>>
>>> arch/powerpc/kernel/exceptions-64s.S:839: Error:
>>> attempt to move .org backwards
>>>
>>> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
>>>
>>> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
>>> forwarding barrier at kernel entry/exit"), which is part of a large patch
>>> series and can not easily be reverted.
>>>
>>> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
>>
>> Michael, I thought this patch series was supposed to fix ppc issues, not
>> add to them :)
>>
>> Any ideas on what to do here?
>
> What exact code do you build?
>
$ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- allmodconfig
$ powerpc64-linux-gcc --version
powerpc64-linux-gcc (GCC) 8.3.0
Guenter
^ permalink raw reply
* Re: [PATCH] vsprintf: Do not break early boot with probing addresses
From: Andy Shevchenko @ 2019-05-09 13:05 UTC (permalink / raw)
To: Petr Mladek
Cc: linux-arch, Sergey Senozhatsky, Heiko Carstens, linux-s390,
linuxppc-dev, Rasmus Villemoes, linux-kernel, Steven Rostedt,
Michal Hocko, Sergey Senozhatsky, Stephen Rothwell,
Linus Torvalds, Martin Schwidefsky, Tobin C . Harding
In-Reply-To: <20190509121923.8339-1-pmladek@suse.com>
On Thu, May 09, 2019 at 02:19:23PM +0200, Petr Mladek wrote:
> The commit 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing
> invalid pointers") broke boot on several architectures. The common
> pattern is that probe_kernel_read() is not working during early
> boot because userspace access framework is not ready.
>
> The check is only the best effort. Let's not rush with it during
> the early boot.
>
> Details:
>
> 1. Report on Power:
>
> Kernel crashes very early during boot with with CONFIG_PPC_KUAP and
> CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
>
> The problem is the combination of some new code called via printk(),
> check_pointer() which calls probe_kernel_read(). That then calls
> allow_user_access() (PPC_KUAP) and that uses mmu_has_feature() too early
> (before we've patched features). With the JUMP_LABEL debug enabled that
> causes us to call printk() & dump_stack() and we end up recursing and
> overflowing the stack.
>
> Because it happens so early you don't get any output, just an apparently
> dead system.
>
> The stack trace (which you don't see) is something like:
>
> ...
> dump_stack+0xdc
> probe_kernel_read+0x1a4
> check_pointer+0x58
> string+0x3c
> vsnprintf+0x1bc
> vscnprintf+0x20
> printk_safe_log_store+0x7c
> printk+0x40
> dump_stack_print_info+0xbc
> dump_stack+0x8
> probe_kernel_read+0x1a4
> probe_kernel_read+0x19c
> check_pointer+0x58
> string+0x3c
> vsnprintf+0x1bc
> vscnprintf+0x20
> vprintk_store+0x6c
> vprintk_emit+0xec
> vprintk_func+0xd4
> printk+0x40
> cpufeatures_process_feature+0xc8
> scan_cpufeatures_subnodes+0x380
> of_scan_flat_dt_subnodes+0xb4
> dt_cpu_ftrs_scan_callback+0x158
> of_scan_flat_dt+0xf0
> dt_cpu_ftrs_scan+0x3c
> early_init_devtree+0x360
> early_setup+0x9c
>
> 2. Report on s390:
>
> vsnprintf invocations, are broken on s390. For example, the early boot
> output now looks like this where the first (efault) should be
> the linux_banner:
>
> [ 0.099985] (efault)
> [ 0.099985] setup: Linux is running as a z/VM guest operating system in 64-bit mode
> [ 0.100066] setup: The maximum memory size is 8192MB
> [ 0.100070] cma: Reserved 4 MiB at (efault)
> [ 0.100100] numa: NUMA mode: (efault)
>
> The reason for this, is that the code assumes that
> probe_kernel_address() works very early. This however is not true on
> at least s390. Uaccess on KERNEL_DS works only after page tables have
> been setup on s390, which happens with setup_arch()->paging_init().
>
> Any probe_kernel_address() invocation before that will return -EFAULT.
>
It's seems as a good enough fix.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Though in all cases would be nice to distinguish error pointers as well.
Something like
if (IS_ERR(ptr))
return err_pointer_str(ptr);
in check_pointer_msg().
> Fixes: 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing invalid pointers")
> Signed-off-by: Petr Mladek <pmladek@suse.com>
> ---
> lib/vsprintf.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 7b0a6140bfad..8b43a883be6b 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -640,8 +640,13 @@ static const char *check_pointer_msg(const void *ptr)
> if (!ptr)
> return "(null)";
>
> - if (probe_kernel_address(ptr, byte))
> - return "(efault)";
> + /* User space address handling is not ready during early boot. */
> + if (system_state <= SYSTEM_BOOTING) {
> + if ((unsigned long)ptr < PAGE_SIZE)
> + return "(efault)";
> + } else {
> + if (probe_kernel_address(ptr, byte))
> + return "(efault)";
>
> return NULL;
> }
> --
> 2.16.4
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] powerpc/32s: fix flush_hash_pages() on SMP
From: Christophe Leroy @ 2019-05-09 12:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
erhard_f
Cc: linuxppc-dev, linux-kernel, stable
flush_hash_pages() runs with data translation off, so current
task_struct has to be accesssed using physical address.
Reported-by: Erhard F. <erhard_f@mailbox.org>
Fixes: f7354ccac844 ("powerpc/32: Remove CURRENT_THREAD_INFO and rename TI_CPU")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/mm/book3s32/hash_low.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/book3s32/hash_low.S b/arch/powerpc/mm/book3s32/hash_low.S
index e27792d0b744..8366c2abeafc 100644
--- a/arch/powerpc/mm/book3s32/hash_low.S
+++ b/arch/powerpc/mm/book3s32/hash_low.S
@@ -539,7 +539,8 @@ _GLOBAL(flush_hash_pages)
#ifdef CONFIG_SMP
lis r9, (mmu_hash_lock - PAGE_OFFSET)@ha
addi r9, r9, (mmu_hash_lock - PAGE_OFFSET)@l
- lwz r8,TASK_CPU(r2)
+ tophys (r8, r2)
+ lwz r8, TASK_CPU(r8)
oris r8,r8,9
10: lwarx r0,0,r9
cmpi 0,r0,0
--
2.13.3
^ permalink raw reply related
* Re: [PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory()
From: David Hildenbrand @ 2019-05-09 12:50 UTC (permalink / raw)
To: Wei Yang
Cc: linux-s390, Michal Hocko, linux-ia64, Pavel Tatashin, linux-sh,
mike.travis@hpe.com, Greg Kroah-Hartman, Rafael J. Wysocki,
Mathieu Malaterre, linux-kernel, Ingo Molnar, linux-mm,
Andrew Banman, Qian Cai, Arun KS, akpm, linuxppc-dev,
Dan Williams, Oscar Salvador
In-Reply-To: <20190509124302.at7jltfrycj7sxbd@master>
On 09.05.19 14:43, Wei Yang wrote:
> On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote:
>> Only memory to be added to the buddy and to be onlined/offlined by
>> user space using memory block devices needs (and should have!) memory
>> block devices.
>>
>> Factor out creation of memory block devices Create all devices after
>> arch_add_memory() succeeded. We can later drop the want_memblock parameter,
>> because it is now effectively stale.
>>
>> Only after memory block devices have been added, memory can be onlined
>> by user space. This implies, that memory is not visible to user space at
>> all before arch_add_memory() succeeded.
>>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
>> Cc: David Hildenbrand <david@redhat.com>
>> Cc: "mike.travis@hpe.com" <mike.travis@hpe.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Ingo Molnar <mingo@kernel.org>
>> Cc: Andrew Banman <andrew.banman@hpe.com>
>> Cc: Oscar Salvador <osalvador@suse.de>
>> Cc: Michal Hocko <mhocko@suse.com>
>> Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
>> Cc: Qian Cai <cai@lca.pw>
>> Cc: Wei Yang <richard.weiyang@gmail.com>
>> Cc: Arun KS <arunks@codeaurora.org>
>> Cc: Mathieu Malaterre <malat@debian.org>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>> drivers/base/memory.c | 70 ++++++++++++++++++++++++++----------------
>> include/linux/memory.h | 2 +-
>> mm/memory_hotplug.c | 15 ++++-----
>> 3 files changed, 53 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
>> index 6e0cb4fda179..862c202a18ca 100644
>> --- a/drivers/base/memory.c
>> +++ b/drivers/base/memory.c
>> @@ -701,44 +701,62 @@ static int add_memory_block(int base_section_nr)
>> return 0;
>> }
>>
>> +static void unregister_memory(struct memory_block *memory)
>> +{
>> + BUG_ON(memory->dev.bus != &memory_subsys);
>> +
>> + /* drop the ref. we got via find_memory_block() */
>> + put_device(&memory->dev);
>> + device_unregister(&memory->dev);
>> +}
>> +
>> /*
>> - * need an interface for the VM to add new memory regions,
>> - * but without onlining it.
>> + * Create memory block devices for the given memory area. Start and size
>> + * have to be aligned to memory block granularity. Memory block devices
>> + * will be initialized as offline.
>> */
>> -int hotplug_memory_register(int nid, struct mem_section *section)
>> +int hotplug_memory_register(unsigned long start, unsigned long size)
>> {
>> - int ret = 0;
>> + unsigned long block_nr_pages = memory_block_size_bytes() >> PAGE_SHIFT;
>> + unsigned long start_pfn = PFN_DOWN(start);
>> + unsigned long end_pfn = start_pfn + (size >> PAGE_SHIFT);
>> + unsigned long pfn;
>> struct memory_block *mem;
>> + int ret = 0;
>>
>> - mutex_lock(&mem_sysfs_mutex);
>> + BUG_ON(!IS_ALIGNED(start, memory_block_size_bytes()));
>> + BUG_ON(!IS_ALIGNED(size, memory_block_size_bytes()));
>
> After this change, the call flow looks like this:
>
> add_memory_resource
> check_hotplug_memory_range
> hotplug_memory_register
>
> Since in check_hotplug_memory_range() has checked the boundary, do we need to
> check here again?
>
I prefer to check for such requirements explicitly in applicable places,
especially if they are placed in different files. Makes code easier to
get. WARN_ON_ONCE will indicate that this has to be assured by the caller.
Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory()
From: Wei Yang @ 2019-05-09 12:43 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-s390, Michal Hocko, linux-ia64, Pavel Tatashin, linux-sh,
mike.travis@hpe.com, Greg Kroah-Hartman, Rafael J. Wysocki,
Mathieu Malaterre, linux-kernel, Ingo Molnar, linux-mm,
Andrew Banman, Qian Cai, Arun KS, akpm, Wei Yang, linuxppc-dev,
Dan Williams, Oscar Salvador
In-Reply-To: <20190507183804.5512-5-david@redhat.com>
On Tue, May 07, 2019 at 08:38:00PM +0200, David Hildenbrand wrote:
>Only memory to be added to the buddy and to be onlined/offlined by
>user space using memory block devices needs (and should have!) memory
>block devices.
>
>Factor out creation of memory block devices Create all devices after
>arch_add_memory() succeeded. We can later drop the want_memblock parameter,
>because it is now effectively stale.
>
>Only after memory block devices have been added, memory can be onlined
>by user space. This implies, that memory is not visible to user space at
>all before arch_add_memory() succeeded.
>
>Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>Cc: "Rafael J. Wysocki" <rafael@kernel.org>
>Cc: David Hildenbrand <david@redhat.com>
>Cc: "mike.travis@hpe.com" <mike.travis@hpe.com>
>Cc: Andrew Morton <akpm@linux-foundation.org>
>Cc: Ingo Molnar <mingo@kernel.org>
>Cc: Andrew Banman <andrew.banman@hpe.com>
>Cc: Oscar Salvador <osalvador@suse.de>
>Cc: Michal Hocko <mhocko@suse.com>
>Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
>Cc: Qian Cai <cai@lca.pw>
>Cc: Wei Yang <richard.weiyang@gmail.com>
>Cc: Arun KS <arunks@codeaurora.org>
>Cc: Mathieu Malaterre <malat@debian.org>
>Signed-off-by: David Hildenbrand <david@redhat.com>
>---
> drivers/base/memory.c | 70 ++++++++++++++++++++++++++----------------
> include/linux/memory.h | 2 +-
> mm/memory_hotplug.c | 15 ++++-----
> 3 files changed, 53 insertions(+), 34 deletions(-)
>
>diff --git a/drivers/base/memory.c b/drivers/base/memory.c
>index 6e0cb4fda179..862c202a18ca 100644
>--- a/drivers/base/memory.c
>+++ b/drivers/base/memory.c
>@@ -701,44 +701,62 @@ static int add_memory_block(int base_section_nr)
> return 0;
> }
>
>+static void unregister_memory(struct memory_block *memory)
>+{
>+ BUG_ON(memory->dev.bus != &memory_subsys);
>+
>+ /* drop the ref. we got via find_memory_block() */
>+ put_device(&memory->dev);
>+ device_unregister(&memory->dev);
>+}
>+
> /*
>- * need an interface for the VM to add new memory regions,
>- * but without onlining it.
>+ * Create memory block devices for the given memory area. Start and size
>+ * have to be aligned to memory block granularity. Memory block devices
>+ * will be initialized as offline.
> */
>-int hotplug_memory_register(int nid, struct mem_section *section)
>+int hotplug_memory_register(unsigned long start, unsigned long size)
> {
>- int ret = 0;
>+ unsigned long block_nr_pages = memory_block_size_bytes() >> PAGE_SHIFT;
>+ unsigned long start_pfn = PFN_DOWN(start);
>+ unsigned long end_pfn = start_pfn + (size >> PAGE_SHIFT);
>+ unsigned long pfn;
> struct memory_block *mem;
>+ int ret = 0;
>
>- mutex_lock(&mem_sysfs_mutex);
>+ BUG_ON(!IS_ALIGNED(start, memory_block_size_bytes()));
>+ BUG_ON(!IS_ALIGNED(size, memory_block_size_bytes()));
After this change, the call flow looks like this:
add_memory_resource
check_hotplug_memory_range
hotplug_memory_register
Since in check_hotplug_memory_range() has checked the boundary, do we need to
check here again?
--
Wei Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH v2 1/8] mm/memory_hotplug: Simplify and fix check_hotplug_memory_range()
From: Wei Yang @ 2019-05-09 12:23 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-s390, Michal Hocko, linux-ia64, Pavel Tatashin, linux-sh,
Mathieu Malaterre, linux-kernel, Wei Yang, linux-mm, Qian Cai,
Arun KS, akpm, linuxppc-dev, Dan Williams, Oscar Salvador
In-Reply-To: <20190507183804.5512-2-david@redhat.com>
On Tue, May 07, 2019 at 08:37:57PM +0200, David Hildenbrand wrote:
>By converting start and size to page granularity, we actually ignore
>unaligned parts within a page instead of properly bailing out with an
>error.
>
>Cc: Andrew Morton <akpm@linux-foundation.org>
>Cc: Oscar Salvador <osalvador@suse.de>
>Cc: Michal Hocko <mhocko@suse.com>
>Cc: David Hildenbrand <david@redhat.com>
>Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
>Cc: Qian Cai <cai@lca.pw>
>Cc: Wei Yang <richard.weiyang@gmail.com>
>Cc: Arun KS <arunks@codeaurora.org>
>Cc: Mathieu Malaterre <malat@debian.org>
>Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Wei Yang <richardw.yang@linux.intel.com>
--
Wei Yang
Help you, Help me
^ permalink raw reply
* [PATCH] vsprintf: Do not break early boot with probing addresses
From: Petr Mladek @ 2019-05-09 12:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-arch, Sergey Senozhatsky, Heiko Carstens, linux-s390,
Rasmus Villemoes, linux-kernel, Steven Rostedt, Michal Hocko,
Sergey Senozhatsky, Stephen Rothwell, Petr Mladek,
Andy Shevchenko, linuxppc-dev, Martin Schwidefsky,
Tobin C . Harding
The commit 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing
invalid pointers") broke boot on several architectures. The common
pattern is that probe_kernel_read() is not working during early
boot because userspace access framework is not ready.
The check is only the best effort. Let's not rush with it during
the early boot.
Details:
1. Report on Power:
Kernel crashes very early during boot with with CONFIG_PPC_KUAP and
CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
The problem is the combination of some new code called via printk(),
check_pointer() which calls probe_kernel_read(). That then calls
allow_user_access() (PPC_KUAP) and that uses mmu_has_feature() too early
(before we've patched features). With the JUMP_LABEL debug enabled that
causes us to call printk() & dump_stack() and we end up recursing and
overflowing the stack.
Because it happens so early you don't get any output, just an apparently
dead system.
The stack trace (which you don't see) is something like:
...
dump_stack+0xdc
probe_kernel_read+0x1a4
check_pointer+0x58
string+0x3c
vsnprintf+0x1bc
vscnprintf+0x20
printk_safe_log_store+0x7c
printk+0x40
dump_stack_print_info+0xbc
dump_stack+0x8
probe_kernel_read+0x1a4
probe_kernel_read+0x19c
check_pointer+0x58
string+0x3c
vsnprintf+0x1bc
vscnprintf+0x20
vprintk_store+0x6c
vprintk_emit+0xec
vprintk_func+0xd4
printk+0x40
cpufeatures_process_feature+0xc8
scan_cpufeatures_subnodes+0x380
of_scan_flat_dt_subnodes+0xb4
dt_cpu_ftrs_scan_callback+0x158
of_scan_flat_dt+0xf0
dt_cpu_ftrs_scan+0x3c
early_init_devtree+0x360
early_setup+0x9c
2. Report on s390:
vsnprintf invocations, are broken on s390. For example, the early boot
output now looks like this where the first (efault) should be
the linux_banner:
[ 0.099985] (efault)
[ 0.099985] setup: Linux is running as a z/VM guest operating system in 64-bit mode
[ 0.100066] setup: The maximum memory size is 8192MB
[ 0.100070] cma: Reserved 4 MiB at (efault)
[ 0.100100] numa: NUMA mode: (efault)
The reason for this, is that the code assumes that
probe_kernel_address() works very early. This however is not true on
at least s390. Uaccess on KERNEL_DS works only after page tables have
been setup on s390, which happens with setup_arch()->paging_init().
Any probe_kernel_address() invocation before that will return -EFAULT.
Fixes: 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing invalid pointers")
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
lib/vsprintf.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 7b0a6140bfad..8b43a883be6b 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -640,8 +640,13 @@ static const char *check_pointer_msg(const void *ptr)
if (!ptr)
return "(null)";
- if (probe_kernel_address(ptr, byte))
- return "(efault)";
+ /* User space address handling is not ready during early boot. */
+ if (system_state <= SYSTEM_BOOTING) {
+ if ((unsigned long)ptr < PAGE_SIZE)
+ return "(efault)";
+ } else {
+ if (probe_kernel_address(ptr, byte))
+ return "(efault)";
return NULL;
}
--
2.16.4
^ permalink raw reply related
* [Bug 203125] Kernel 5.1-rc1 fails to boot on a PowerMac G4 3,6: Caused by (from SRR1=141020): Transfer error ack signal
From: bugzilla-daemon @ 2019-05-09 11:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203125-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #9 from Erhard F. (erhard_f@mailbox.org) ---
@Christophe: Oops, accidentally I trashed your last comment. Sorry! This patch
didn't apply either. There is no book3s32 directory in my linux-stable tree,
the hash_*.S files are directly in mm/
But does not matter, your code change works!
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 203125] Kernel 5.1-rc1 fails to boot on a PowerMac G4 3,6: Caused by (from SRR1=141020): Transfer error ack signal
From: bugzilla-daemon @ 2019-05-09 11:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203125-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #8 from Erhard F. (erhard_f@mailbox.org) ---
I tried to apply the patch on top of 5.1.0 but it did not work out 'cause there
is no arch/powerpc/mm/book3s32/hash_low.S. The correct file on my system seemed
arch/powerpc/mm/hash_low_32.S, but changing the path in the patch did not work
either.
What actually did work was manually applying your proposed change in
arch/powerpc/mm/book3s32/hash_low.S! Now the G4 boots up fine with 5.1.0 as it
did with 5.0.x.
Many thanks for the fix!
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH] powerpc/ftrace: Enable C Version of recordmcount
From: Christophe Leroy @ 2019-05-09 11:27 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87ef59wz8n.fsf@concordia.ellerman.id.au>
Le 08/05/2019 à 02:45, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>> Selects HAVE_C_RECORDMCOUNT to use the C version of the recordmcount
>> intead of the old Perl Version of recordmcount.
>>
>> This should improve build time. It also seems like the old Perl Version
>> misses some calls to _mcount that the C version finds.
>
> That would make this a bug fix possibly for stable even.
>
> Any more details on what the difference is, is it just some random
> subset of functions or some pattern?
I have not been able to identify any pattern. Will add a few details in
the 'issue' on github.
Christophe
>
> cheers
>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 2711aac24621..d87de4f9da61 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -180,6 +180,7 @@ config PPC
>> select HAVE_ARCH_NVRAM_OPS
>> select HAVE_ARCH_SECCOMP_FILTER
>> select HAVE_ARCH_TRACEHOOK
>> + select HAVE_C_RECORDMCOUNT
>> select HAVE_CBPF_JIT if !PPC64
>> select HAVE_STACKPROTECTOR if PPC64 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r13)
>> select HAVE_STACKPROTECTOR if PPC32 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r2)
>> --
>> 2.13.3
^ permalink raw reply
* [Bug 203125] Kernel 5.1-rc1 fails to boot on a PowerMac G4 3,6: Caused by (from SRR1=141020): Transfer error ack signal
From: bugzilla-daemon @ 2019-05-09 10:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203125-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #7 from Christophe Leroy (christophe.leroy@c-s.fr) ---
On 05/09/2019 10:05 AM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=203125
>
> Christophe Leroy (christophe.leroy@c-s.fr) changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |christophe.leroy@c-s.fr
>
> --- Comment #5 from Christophe Leroy (christophe.leroy@c-s.fr) ---
> Apparently, MSR DR is not sent and DAR has value 0xc0090654, meaning that a
> virt address tries to get accessed while in real mode.
>
Could you try the patch below:
diff --git a/arch/powerpc/mm/book3s32/hash_low.S
b/arch/powerpc/mm/book3s32/hash_low.S
index e27792d0b744..8366c2abeafc 100644
--- a/arch/powerpc/mm/book3s32/hash_low.S
+++ b/arch/powerpc/mm/book3s32/hash_low.S
@@ -539,7 +539,8 @@ _GLOBAL(flush_hash_pages)
#ifdef CONFIG_SMP
lis r9, (mmu_hash_lock - PAGE_OFFSET)@ha
addi r9, r9, (mmu_hash_lock - PAGE_OFFSET)@l
- lwz r8,TASK_CPU(r2)
+ tophys (r8, r2)
+ lwz r8, TASK_CPU(r8)
oris r8,r8,9
10: lwarx r0,0,r9
cmpi 0,r0,0
Christophe
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply related
* [Bug 203125] Kernel 5.1-rc1 fails to boot on a PowerMac G4 3,6: Caused by (from SRR1=141020): Transfer error ack signal
From: bugzilla-daemon @ 2019-05-09 10:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203125-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #6 from Christophe Leroy (christophe.leroy@c-s.fr) ---
Try followin change:
diff --git a/arch/powerpc/mm/book3s32/hash_low.S
b/arch/powerpc/mm/book3s32/hash_low.S
index e27792d0b744..8366c2abeafc 100644
--- a/arch/powerpc/mm/book3s32/hash_low.S
+++ b/arch/powerpc/mm/book3s32/hash_low.S
@@ -539,7 +539,8 @@ _GLOBAL(flush_hash_pages)
#ifdef CONFIG_SMP
lis r9, (mmu_hash_lock - PAGE_OFFSET)@ha
addi r9, r9, (mmu_hash_lock - PAGE_OFFSET)@l
- lwz r8,TASK_CPU(r2)
+ tophys (r8, r2)
+ lwz r8, TASK_CPU(r8)
oris r8,r8,9
10: lwarx r0,0,r9
cmpi 0,r0,0
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply related
* Re: [Bug 203125] Kernel 5.1-rc1 fails to boot on a PowerMac G4 3,6: Caused by (from SRR1=141020): Transfer error ack signal
From: Christophe Leroy @ 2019-05-09 10:22 UTC (permalink / raw)
To: bugzilla-daemon, linuxppc-dev
In-Reply-To: <bug-203125-206035-A0uW2ahLrr@https.bugzilla.kernel.org/>
On 05/09/2019 10:05 AM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=203125
>
> Christophe Leroy (christophe.leroy@c-s.fr) changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |christophe.leroy@c-s.fr
>
> --- Comment #5 from Christophe Leroy (christophe.leroy@c-s.fr) ---
> Apparently, MSR DR is not sent and DAR has value 0xc0090654, meaning that a
> virt address tries to get accessed while in real mode.
>
Could you try the patch below:
diff --git a/arch/powerpc/mm/book3s32/hash_low.S
b/arch/powerpc/mm/book3s32/hash_low.S
index e27792d0b744..8366c2abeafc 100644
--- a/arch/powerpc/mm/book3s32/hash_low.S
+++ b/arch/powerpc/mm/book3s32/hash_low.S
@@ -539,7 +539,8 @@ _GLOBAL(flush_hash_pages)
#ifdef CONFIG_SMP
lis r9, (mmu_hash_lock - PAGE_OFFSET)@ha
addi r9, r9, (mmu_hash_lock - PAGE_OFFSET)@l
- lwz r8,TASK_CPU(r2)
+ tophys (r8, r2)
+ lwz r8, TASK_CPU(r8)
oris r8,r8,9
10: lwarx r0,0,r9
cmpi 0,r0,0
Christophe
^ permalink raw reply related
* [Bug 203125] Kernel 5.1-rc1 fails to boot on a PowerMac G4 3,6: Caused by (from SRR1=141020): Transfer error ack signal
From: bugzilla-daemon @ 2019-05-09 10:05 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203125-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203125
Christophe Leroy (christophe.leroy@c-s.fr) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |christophe.leroy@c-s.fr
--- Comment #5 from Christophe Leroy (christophe.leroy@c-s.fr) ---
Apparently, MSR DR is not sent and DAR has value 0xc0090654, meaning that a
virt address tries to get accessed while in real mode.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ 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