From patchwork Tue Apr 8 14:24:35 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arun KS X-Patchwork-Id: 3949061 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 01769BFF02 for ; Tue, 8 Apr 2014 14:27:13 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id F0293202E6 for ; Tue, 8 Apr 2014 14:27:11 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B1596202B4 for ; Tue, 8 Apr 2014 14:27:10 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WXWyF-0004nt-Jj; Tue, 08 Apr 2014 14:25:52 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WXWxq-0000SD-Tk; Tue, 08 Apr 2014 14:25:26 +0000 Received: from mail-pa0-x22f.google.com ([2607:f8b0:400e:c03::22f]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WXWxn-0000Qk-Nz for linux-arm-kernel@lists.infradead.org; Tue, 08 Apr 2014 14:25:25 +0000 Received: by mail-pa0-f47.google.com with SMTP id lj1so1103027pab.20 for ; Tue, 08 Apr 2014 07:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=98GbOuqlIfsEc3oSgynsvaG/xCGvE+5UKBY16srO3+g=; b=L9iaVyGN95qNoYQYHXdoR9e93UZ/b3EXZr2XqTXr+4htCdSPTk2XDNrecL3yT+QZzr nFXrLqLrLL+gF7o7sJmusVL9SNN8uozXh0OddTO+ykC6hlAT6LWYOgRnL6gYNT9CKKqn vvtSCdWGnqRRrdUd6pfBYjnMBGtbEMzjSMiokrLdu1y7TE/nX38MrA3nzDImH4tt0mmo yHNBKbd9W/fFc1SRAdzsUb3r9yt/776URCzxqF4d/V/CDPF8QouoZH1kedr8Pf3+dkbk SZkDzFm5j/gQvtiIyLzRypq7v4VULQMsAOSY+uyRqfOZG0k+hPeDXChP2w3tPL5nmKS+ 0rNg== X-Received: by 10.68.254.5 with SMTP id ae5mr4905864pbd.83.1396967102252; Tue, 08 Apr 2014 07:25:02 -0700 (PDT) Received: from localhost ([122.179.46.100]) by mx.google.com with ESMTPSA id y4sm4958305pbk.76.2014.04.08.07.24.58 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 08 Apr 2014 07:25:01 -0700 (PDT) From: arunks.linux@gmail.com To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] ARM: Modify ldrt fixup handler to re-execute the userspace instruction Date: Tue, 8 Apr 2014 19:54:35 +0530 Message-Id: <1396967075-11988-1-git-send-email-arunks.linux@gmail.com> X-Mailer: git-send-email 1.7.9.5 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140408_102523_945912_6F9CE70D X-CRM114-Status: GOOD ( 14.11 ) X-Spam-Score: -2.0 (--) Cc: catalin.marinas@arm.com, stable@vger.kernel.org, Danesh Petigara , Vinayak Menon , Arun KS , Arun KS X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 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.4 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, T_DKIM_INVALID, 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 From: Arun KS We will reach fixup handler when one thread(say cpu0) caused an undefined exception, while another thread(say cpu1) is unmmaping the page. Fixup handler returns to the next userspace instruction which has caused the undef execption, rather than going to the same instruction. ARM ARM says that after undefined exception, the PC will be pointing to the next instruction. ie +4 offset in case of ARM and +2 in case of Thumb And there is no correction offset passed to vector_stub in case of undef exception. File: arch/arm/kernel/entry-armv.S +1085 vector_stub und, UND_MODE During an undefined exception, in normal scenario(ie when ldrt instruction does not cause an abort) after resorting the context in VFP hardware, the PC is modified as show below before jumping to ret_from_exception which is in r9. File: arch/arm/vfp/vfphw.S +169 @ The context stored in the VFP hardware is up to date with this thread vfp_hw_state_valid: tst r1, #FPEXC_EX bne process_exception @ might as well handle the pending @ exception before retrying branch @ out before setting an FPEXC that @ stops us reading stuff VFPFMXR FPEXC, r1 @ Restore FPEXC last sub r2, r2, #4 @ Retry current instruction - if Thumb str r2, [sp, #S_PC] @ mode it's two 16-bit instructions, @ else it's one 32-bit instruction, so @ always subtract 4 from the following @ instruction address. But if ldrt results in an abort, we reach the fixup handler and return to ret_from_execption without correcting the pc. This patch modifes the fixup handler to re-execute the same instruction which caused undefined execption. Signed-off-by: Danesh Petigara Signed-off-by: Vinayak Menon Signed-off-by: Arun KS Acked-by: Catalin Marinas Cc: [2.6.32+] --- arch/arm/kernel/entry-armv.S | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 1879e8d..3fa745f 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -484,7 +484,8 @@ ENDPROC(__und_usr) */ .pushsection .fixup, "ax" .align 2 -4: mov pc, r9 +4: str r4, [sp, #S_PC] @ retry current instruction + mov pc, r9 .popsection .pushsection __ex_table,"a" .long 1b, 4b