All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: "linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
Subject: Re: RESEND: Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y
Date: Fri, 14 Feb 2020 12:02:40 +0100	[thread overview]
Message-ID: <bd705040-914b-21a8-dfb2-c98bc8c96609@c-s.fr> (raw)
In-Reply-To: <02ce1278-5880-063c-2281-178edd541232@c-s.fr>



Le 14/02/2020 à 07:24, Christophe Leroy a écrit :
> Larry,
> 
> Le 14/02/2020 à 00:09, Larry Finger a écrit :
>> Christophe,
>>
>> With this patch, it gets further. Sometime after the boot process 
>> tries to start process init, it crashes with the unable to read data 
>> at 0x000157a0 with a faulting address of 0xc001683c. The screenshot is 
>> attached and the gzipped vmlinux is at 
>> http://www.lwfinger.com/download/vmlinux2.gz. The patches that were 
>> applied for this kernel are also attached,
>>
> 
> 
> Did you try with the patch at https://patchwork.ozlabs.org/patch/1237387/ ?
> 
> I see the problem happens in kprobe_handler(). Can you try without 
> CONFIG_KPROBE ?
> 

In fact, you hit two bugs. The first one is due to CONFIG_VMAP_STACK. 
The second one has always existed (at least since kernel source tree has 
been in git).

First bug is in function enter_rtas() which tries to read data on stack 
by using the linear physical address translation. This cannot be used 
with VM stack, it must re-enable data MMU translation to access data on 
the stack.

Second bug is in kprobe_handler() function, which does:

	if (*addr != BREAKPOINT_INSTRUCTION)

addr is the address where the 'trap' happened. When a trap happens with 
MMU disabled, addr contains the physical address of the trap. 
kprobe_handler() tries to read the instruction using physical address 
whereas MMU is enabled, so you get a bad access either because the said 
address is not mapped, or because access to userspace is not allowed.


Due to the first bug, you get a 'machine check', and as 
current->thread.rtas_sp has not been cleared yet, the machine check 
handler jumps to 'machine_check_in_rtas'.

machine_check_in_rtas does a trap, which in turn triggers the second bug.


Once the first bug is fixed, the second one should not popup.

Can you test patch https://patchwork.ozlabs.org/patch/1237929/ that 
fixes the first bug ?

Christophe

  reply	other threads:[~2020-02-14 11:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f7565b89-c8b2-d2e7-929e-4b1abf72fc63@lwfinger.net>
     [not found] ` <159ed5d8-376b-1642-fb4b-01406d671cf1@c-s.fr>
     [not found]   ` <6a1802b8-c6a7-d091-1036-689e089b786f@lwfinger.net>
2020-02-11  6:55     ` Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y Christophe Leroy
2020-02-11 16:06       ` Larry Finger
2020-02-11 19:23         ` Christophe Leroy
     [not found]           ` <1787b507-dfbf-7801-f7d4-a1547e9bd588@lwfinger.net>
2020-02-13 11:23             ` Christophe Leroy
     [not found]           ` <7f63e8a8-95c5-eeca-dc79-3c13f4d98d39@lwfinger.net>
2020-02-13 14:43             ` RESEND: " Christophe Leroy
2020-02-13 23:09               ` Larry Finger
2020-02-14  6:24                 ` Christophe Leroy
2020-02-14 11:02                   ` Christophe Leroy [this message]
2020-02-14 18:20                   ` Larry Finger
2020-02-14 18:24                   ` Larry Finger
2020-02-14 19:35                     ` Christophe Leroy
2020-02-15  2:42                       ` Larry Finger
2020-02-15  7:55                         ` Christophe Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bd705040-914b-21a8-dfb2-c98bc8c96609@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=Larry.Finger@lwfinger.net \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.