From patchwork Sat Sep 5 13:48:38 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Robert Jarzmik X-Patchwork-Id: 7129351 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1BEE49F1CD for ; Sat, 5 Sep 2015 13:55:50 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 1568720891 for ; Sat, 5 Sep 2015 13:55:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A0AFC2086A for ; Sat, 5 Sep 2015 13:55:47 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZYDuh-0000De-Lo; Sat, 05 Sep 2015 13:53:51 +0000 Received: from smtp10.smtpout.orange.fr ([80.12.242.132] helo=smtp.smtpout.orange.fr) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZYDue-00008u-5O for linux-arm-kernel@lists.infradead.org; Sat, 05 Sep 2015 13:53:49 +0000 Received: from belgarion ([109.222.247.56]) by mwinf5d45 with ME id DRtJ1r00L1DkrDp03RtKfw; Sat, 05 Sep 2015 15:53:25 +0200 X-ME-Helo: belgarion X-ME-Auth: amFyem1pay5yb2JlcnRAb3JhbmdlLmZy X-ME-Date: Sat, 05 Sep 2015 15:53:25 +0200 X-ME-IP: 109.222.247.56 From: Robert Jarzmik To: Russell King - ARM Linux , Dave Martin Subject: Re: [PATCH] ARM: fix alignement of __bug_table section entries References: <1441175009-26730-1-git-send-email-robert.jarzmik@free.fr> <20150902103955.GF6281@e103592.cambridge.arm.com> X-URL: http://belgarath.falguerolles.org/ Date: Sat, 05 Sep 2015 15:48:38 +0200 In-Reply-To: <20150902103955.GF6281@e103592.cambridge.arm.com> (Dave Martin's message of "Wed, 2 Sep 2015 11:39:56 +0100") Message-ID: <878u8lx9hl.fsf@belgarion.home> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150905_065348_667822_8889B3B7 X-CRM114-Status: GOOD ( 17.65 ) X-Spam-Score: -1.9 (-) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Dave Martin writes: > On Wed, Sep 02, 2015 at 08:23:29AM +0200, Robert Jarzmik wrote: >> On old ARM chips, unaligned accesses to memory are not trapped and >> fixed. On module load, symbols are relocated, and the relocation of >> __bug_table symbols is done on a u32 basis. Yet the section is not >> aligned to a multiple of 4 address, but to a multiple of 2. Hi Russell, I dug deeper, and got another stack, unrelated to modules insertion but related to alignement fault (see [1] for reference). As before, this didn't happen on v4.1, but happens on linux-next. I'm wondering if alignement fixup does work in my case and if I understand it. 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 The instruction (as seen with vmlinux disassembly or JTAG memory dump) is : 0xc02b37c8 <+372>: b2 50 c6 10 strhne r5, [r6], #2 I must admit I fail to see how the following "fixup:" label can be reached with a "missed" copy_from_user() (fault == 4). This is probably what happened to me with the modules __bug_table section, and it will continue to happen until I understand why this copy fails. It's really odd nobody but me faces this issue. Cheers. ============= #0: pxa2xx-ac97 (Wolfson WM9713,WM9714) RJK: fault=4 instr=0x00000000 instrptr=0xc02b37c8 thumb_mode=0 tinstr=0x0000 &Unable to handle kernel paging request at virtual address c3057661 &pgd = c0004000 "[c3057661] *pgd=a300040e(bad) Internal error: Oops: 803 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.0-rc8-next-20150828+ #900 Hardware name: MIO A701 task: c3858bc0 ti: c385c000 task.ti: c385c000 PC is at doc_read_data_area+0x174/0x370 LR is at doc_read_page_getbytes+0x58/0x78 pc : [] lr : [] psr: a8000013 sp : c385d8e0 ip : c07142b8 fp : c385d91c r10: c3aac540 r9 : c070ffc0 r8 : c385c000 @QGi r7 : 00000002 r6 : c3057661 r5 : 0000c1e5 r4 : 0000000b r3 : 0000000a r2 : 0000000b r1 : c3057661 r0 : 00000000 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 0000397f Table: a0004000 DAC: 00000053 Process swapper (pid: 1, stack limit = 0xc385c198) Stack: (0xc385d8e0 to 0xc385e000) d8e0: 00000000 c02b3a34 00000001 0000000a c385d914 c3057660 0000000c c3aac540 ... chop chop ... dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 f3ff8cdd 4cf3d76f [] (doc_read_data_area) from [] (doc_read_page_getbytes+0x58/0x78) [] (doc_read_page_getbytes) from [] (doc_read_oob+0x22c/0x75c) [] (doc_read_oob) from [] (doc_read+0x64/0x74) [] (doc_read) from [] (part_read+0x58/0x9c) [] (part_read) from [] (mtd_read+0x88/0xbc) [] (mtd_read) from [] (ubi_io_read+0x16c/0x358) [] (ubi_io_read) from [] (ubi_eba_read_leb+0x384/0x4d4) [] (ubi_eba_read_leb) from [] (ubi_leb_read+0xd4/0x134) [] (ubi_leb_read) from [] (ubifs_leb_read+0x3c/0xa8)s [] (ubifs_leb_read) from [] (ubifs_read_nnode+0xec/0x200) [] (ubifs_read_nnode) from [] (ubifs_lpt_lookup_dirty+0x38/0x330) [] (ubifs_lpt_lookup_dirty) from [] (ubifs_replay_journal+0x3c/0x1b38) [] (ubifs_replay_journal) from [] (ubifs_mount+0x1444/0x2410) [] (ubifs_mount) from [] (mount_fs+0x24/0xb0) [] (mount_fs) from [] (vfs_kern_mount+0x58/0x124) [] (vfs_kern_mount) from [] (do_mount+0xb40/0xd10) [] (do_mount) from [] (SyS_mount+0x84/0xb0) [] (SyS_mount) from [] (mount_block_root+0x12c/0x2dc) [] (mount_block_root) from [] (prepare_namespace+0x98/0x1bc) [] (prepare_namespace) from [] (kernel_init_freeable+0x188/0x1d4) [] (kernel_init_freeable) from [] (kernel_init+0x18/0xfc) [] (kernel_init) from [] (ret_from_fork+0x14/0x28) Code: 1a000060 e51b3030 e3560000 e2877002 (10c650b2) ---[ end trace a0bcca195299a22d ]--- [2] Debug patch =============== diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c index 2c0c541c60ca..b0897da5456c 100644 --- a/arch/arm/mm/alignment.c +++ b/arch/arm/mm/alignment.c @@ -787,6 +787,8 @@ 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 instrptr=0x%08lx thumb_mode=%lu tinstr=0x%04x\n", + fault, instr, instrptr, thumb_mode(regs), tinstr); if (fault) { type = TYPE_FAULT; goto bad_or_fault;