From: Robert Jarzmik <robert.jarzmik@free.fr> To: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Dave Martin <Dave.Martin@arm.com>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] ARM: fix alignement of __bug_table section entries Date: Sat, 05 Sep 2015 19:10:49 +0200 [thread overview] Message-ID: <87y4gkx04m.fsf@belgarion.home> (raw) In-Reply-To: <20150905142519.GN21084@n2100.arm.linux.org.uk> (Russell King's message of "Sat, 5 Sep 2015 15:25:19 +0100") Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > On Sat, Sep 05, 2015 at 03:48:38PM +0200, Robert Jarzmik wrote: >> This time I took my JTAG to have a look at the flow, in arch/arm/mm/alignment.c, >> where I added the small chunk in [2], which gave in my case : >> RJK: fault=4 instr=0x00000000 instrptr=0xc02b37c8 thumb_mode=0 tinstr=0x0000 > > Right, so as fault is nonzero, this means that we were unable to read the > instruction. That seems mad though - the instruction pointer is certainly > valid, and as we're using probe_kernel_address(), that switches to the > kernel "segment" before trying to read kernel addresses. That should > mean that __copy_from_user_inatomic() is able to read the instruction. > > I think this is the root cause of the issue. And there is more madness to come : I tried to "reread" the instruction [1] a second time if the first result was 4 : RJK: fault=4 instr=0x00000000(@c385d72c) instrptr=0xc02b39e8 thumb_mode=0 tinstr=0x0000 RJK: reread instruction: [0xc02b39e8] = 0x10c650b2: 0 Guess what, the second probe_kernel_address() with the same parameters returns 0, and everything works. It's insane. >> Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > It seems you have SW_DOMAIN_PAN enabled. That's the default arch/arm/Kconfig implies. And ... this is what also _is_ the cause of this behavior : removing SW_DOMAIN_PAN makes all my pxa boards work again !!! Moreover, this is consistent with the fact that this commit is in linux-next but not in v4.1 : a5e090acbf54 ("ARM: software-based priviledged-no-access support") So the issue is around this SW_DOMAIN_PAN, at least on PXA. -- Robert [1] @@ -787,6 +798,15 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs) instr = __mem_to_opcode_arm(instr); } + pr_info("RJK: fault=%d instr=0x%08lx(@%p) instrptr=0x%08lx thumb_mode=%lu tinstr=0x%04x\n", + fault, instr, &instr, instrptr, thumb_mode(regs), tinstr); + if (fault == 4 && !thumb_mode(regs)) { + fault = probe_kernel_address(instrptr, instr); + pr_info("RJK: reread instruction: [0x%08lx] = 0x%08lx: %u\n", + instrptr, instr, fault); + rjk_debug_point(instrptr); + } + if (fault) { type = TYPE_FAULT; goto bad_or_fault;
WARNING: multiple messages have this Message-ID (diff)
From: robert.jarzmik@free.fr (Robert Jarzmik) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] ARM: fix alignement of __bug_table section entries Date: Sat, 05 Sep 2015 19:10:49 +0200 [thread overview] Message-ID: <87y4gkx04m.fsf@belgarion.home> (raw) In-Reply-To: <20150905142519.GN21084@n2100.arm.linux.org.uk> (Russell King's message of "Sat, 5 Sep 2015 15:25:19 +0100") Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > On Sat, Sep 05, 2015 at 03:48:38PM +0200, Robert Jarzmik wrote: >> This time I took my JTAG to have a look at the flow, in arch/arm/mm/alignment.c, >> where I added the small chunk in [2], which gave in my case : >> RJK: fault=4 instr=0x00000000 instrptr=0xc02b37c8 thumb_mode=0 tinstr=0x0000 > > Right, so as fault is nonzero, this means that we were unable to read the > instruction. That seems mad though - the instruction pointer is certainly > valid, and as we're using probe_kernel_address(), that switches to the > kernel "segment" before trying to read kernel addresses. That should > mean that __copy_from_user_inatomic() is able to read the instruction. > > I think this is the root cause of the issue. And there is more madness to come : I tried to "reread" the instruction [1] a second time if the first result was 4 : RJK: fault=4 instr=0x00000000(@c385d72c) instrptr=0xc02b39e8 thumb_mode=0 tinstr=0x0000 RJK: reread instruction: [0xc02b39e8] = 0x10c650b2: 0 Guess what, the second probe_kernel_address() with the same parameters returns 0, and everything works. It's insane. >> Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > It seems you have SW_DOMAIN_PAN enabled. That's the default arch/arm/Kconfig implies. And ... this is what also _is_ the cause of this behavior : removing SW_DOMAIN_PAN makes all my pxa boards work again !!! Moreover, this is consistent with the fact that this commit is in linux-next but not in v4.1 : a5e090acbf54 ("ARM: software-based priviledged-no-access support") So the issue is around this SW_DOMAIN_PAN, at least on PXA. -- Robert [1] @@ -787,6 +798,15 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs) instr = __mem_to_opcode_arm(instr); } + pr_info("RJK: fault=%d instr=0x%08lx(@%p) instrptr=0x%08lx thumb_mode=%lu tinstr=0x%04x\n", + fault, instr, &instr, instrptr, thumb_mode(regs), tinstr); + if (fault == 4 && !thumb_mode(regs)) { + fault = probe_kernel_address(instrptr, instr); + pr_info("RJK: reread instruction: [0x%08lx] = 0x%08lx: %u\n", + instrptr, instr, fault); + rjk_debug_point(instrptr); + } + if (fault) { type = TYPE_FAULT; goto bad_or_fault;
next prev parent reply other threads:[~2015-09-05 17:15 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-09-02 6:23 [PATCH] ARM: fix alignement of __bug_table section entries Robert Jarzmik 2015-09-02 6:23 ` Robert Jarzmik 2015-09-02 10:39 ` Dave Martin 2015-09-02 10:39 ` Dave Martin 2015-09-05 13:48 ` Robert Jarzmik 2015-09-05 13:48 ` Robert Jarzmik 2015-09-05 14:25 ` Russell King - ARM Linux 2015-09-05 14:25 ` Russell King - ARM Linux 2015-09-05 17:10 ` Robert Jarzmik [this message] 2015-09-05 17:10 ` Robert Jarzmik 2015-09-05 20:38 ` Russell King - ARM Linux 2015-09-05 20:38 ` Russell King - ARM Linux 2015-09-05 22:12 ` Robert Jarzmik 2015-09-05 22:12 ` Robert Jarzmik 2015-09-06 17:25 ` Robert Jarzmik 2015-09-06 17:25 ` Robert Jarzmik 2015-09-06 19:48 ` Russell King - ARM Linux 2015-09-06 19:48 ` Russell King - ARM Linux 2015-09-06 21:31 ` Robert Jarzmik 2015-09-06 21:31 ` Robert Jarzmik 2015-09-06 23:54 ` Russell King - ARM Linux 2015-09-06 23:54 ` Russell King - ARM Linux 2015-09-08 17:01 ` Robert Jarzmik 2015-09-08 17:01 ` Robert Jarzmik 2015-09-08 20:08 ` Russell King - ARM Linux 2015-09-08 20:08 ` Russell King - ARM Linux 2015-09-08 20:46 ` Robert Jarzmik 2015-09-08 20:46 ` Robert Jarzmik 2015-09-09 23:06 ` Robert Jarzmik 2015-09-09 23:06 ` Robert Jarzmik 2015-09-10 19:01 ` Robert Jarzmik 2015-09-10 19:01 ` Robert Jarzmik 2015-09-10 19:16 ` Russell King - ARM Linux 2015-09-10 19:16 ` Russell King - ARM Linux 2015-09-10 20:53 ` Robert Jarzmik 2015-09-10 20:53 ` Robert Jarzmik 2015-09-11 9:54 ` Russell King - ARM Linux 2015-09-11 9:54 ` Russell King - ARM Linux 2015-09-11 9:56 ` [PATCH 1/2] ARM: domains: thread_info.h no longer needs asm/domains.h Russell King 2015-09-11 9:56 ` Russell King 2015-09-11 9:56 ` [PATCH 2/2] ARM: domains: add memory dependencies to get_domain/set_domain Russell King 2015-09-11 9:56 ` Russell King 2015-09-11 14:56 ` Robert Jarzmik 2015-09-11 14:56 ` Robert Jarzmik 2015-09-11 15:10 ` Russell King - ARM Linux 2015-09-11 15:10 ` Russell King - ARM Linux 2015-09-11 15:40 ` Robert Jarzmik 2015-09-11 15:40 ` Robert Jarzmik
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=87y4gkx04m.fsf@belgarion.home \ --to=robert.jarzmik@free.fr \ --cc=Dave.Martin@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ /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: linkBe 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.