From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Nov 2017 00:49:30 +0100 (CET) Received: from 19pmail.ess.barracuda.com ([64.235.150.245]:51236 "EHLO 19pmail.ess.barracuda.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23991940AbdJaXtXPv74U (ORCPT ); Wed, 1 Nov 2017 00:49:23 +0100 Received: from MIPSMAIL01.mipstec.com (mailrelay.mips.com [12.201.5.28]) by mx29.ess.sfj.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 31 Oct 2017 23:48:58 +0000 Received: from localhost (192.168.154.110) by MIPSMAIL01.mipstec.com (10.20.43.31) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 31 Oct 2017 16:48:07 -0700 Date: Tue, 31 Oct 2017 23:48:53 +0000 From: James Hogan To: Corey Minyard CC: Matt Redfearn , Ralf Baechle , Matthew Fortune , , , "Jason A. Donenfeld" , Paul Burton Subject: Re: [PATCH] MIPS: Fix exception entry when CONFIG_EVA enabled Message-ID: <20171031234853.GD15260@jhogan-linux> References: <1507712360-20657-1-git-send-email-matt.redfearn@mips.com> <605f6a96-a843-085c-efc6-a2c0f2afd84a@mvista.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ABTtc+pdwF7KHXCz" Content-Disposition: inline In-Reply-To: <605f6a96-a843-085c-efc6-a2c0f2afd84a@mvista.com> User-Agent: Mutt/1.7.2 (2016-11-26) X-Originating-IP: [192.168.154.110] X-BESS-ID: 1509493723-637139-14738-368075-4 X-BESS-VER: 2017.12-r1710252241 X-BESS-Apparent-Source-IP: 12.201.5.28 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.186465 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 60625 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: james.hogan@mips.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips --ABTtc+pdwF7KHXCz Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 11, 2017 at 08:12:31AM -0500, Corey Minyard wrote: > On 10/11/2017 03:59 AM, Matt Redfearn wrote: > > Commit 9fef68686317b ("MIPS: Make SAVE_SOME more standard") made several > > changes to the order in which registers are saved in the SAVE_SOME > > macro, used by exception handlers to save the processor state. In > > particular, it removed the > > move k1, sp > > in the delay slot of the branch testing if the processor is already in > > kernel mode. This is replaced later in the macro by a > > move k0, sp > > When CONFIG_EVA is disabled, this instruction actually appears in the > > delay slot of the branch. However, when CONFIG_EVA is enabled, instead > > the RPS workaround of > > MFC0 k0, CP0_ENTRYHI > > appears in the delay slot. This results in k0 not containing the stack > > pointer, but some unrelated value, which is then saved to the kernel > > stack. On exit from the exception, this bogus value is restored to the > > stack pointer, resulting in an OOPS. > > > > Fix this by moving the save of SP in k0 explicitly in the delay slot of > > the branch, outside of the CONFIG_EVA section, restoring the expected > > instruction ordering when CONFIG_EVA is active. > > > > Fixes: 9fef68686317b ("MIPS: Make SAVE_SOME more standard") > > Signed-off-by: Matt Redfearn > > Reported-by: Vladimir Kondratiev >=20 > I looked this over pretty carefully and it looks correct to me.=C2=A0 It= =20 > makes no difference > in the instructions generated by the non-EVA case.=C2=A0 I shouldn't have= =20 > missed this :(. >=20 > Reviewed-by: Corey Minyard Yeh, having stared at it for a little while it looks correct to me too. Reviewed-by: James Hogan Cheers James --ABTtc+pdwF7KHXCz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEd80NauSabkiESfLYbAtpk944dnoFAln5C90ACgkQbAtpk944 dnoa+g//bueyNffOEKJETzj+ErDTSSO0WpbJRJKK0AfKoct54YFUbr37ErVGUb/L MkMtgyfqdm4uutAhCp90Jn70ZOEAlheb2MjbnHvp5oNJ7PgohJkzocc3x5xA2B3F YbuIaTmfUa1W93h3+YSmE0DYYN7uas+j6AFoGf9Q6KryRoKbrHwnxEy8vhLJGFvd 7szraNYk37S/nKTASAQmznNrAkjWeAbJ5qSvzPh0Ll3WDPGMPq6tAs+WoZrS1pmr 23GLs+Jc8y2LLlMFjRiid1majATC9kcljlXSC8diq9b8TopPRhRx2ciuiaLeK2P9 IkriDqu/313ADgi9/3UdJK/UBwz4nYbwo9z++Xv8DQzSH4RwDm/UDr9cJK1xBJm7 kZ2s8/z2i5KFne9kqEOs1AjqhRWQtt4P6AnDY3b75/109wQB6zk2m3RtezB8DBP3 qOhrCecCnnyk6RrenuQm9yXYAnH83GVVWUmN7z0mtAaeNZCcDFZckvGILM8evRvI A66/xSg3ACmOJbKS1XCtXwmKoLDdieKstmZCWSFmBXNHmzye4343RG6dZeWD3FvD hhaKWoTKl3VpKoyA3trnCulPhTrX6heuIJF+Jyah+0sZjOiCtlFDQN8J58k755XY mgb2xe9jiUw+qU6v4GMQ6Fuw3fh/PxLsTUAc7XZYFfI58HxB+0g= =/GEg -----END PGP SIGNATURE----- --ABTtc+pdwF7KHXCz-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 19pmail.ess.barracuda.com ([64.235.150.245]:51236 "EHLO 19pmail.ess.barracuda.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23991940AbdJaXtXPv74U (ORCPT ); Wed, 1 Nov 2017 00:49:23 +0100 Date: Tue, 31 Oct 2017 23:48:53 +0000 From: James Hogan Subject: Re: [PATCH] MIPS: Fix exception entry when CONFIG_EVA enabled Message-ID: <20171031234853.GD15260@jhogan-linux> References: <1507712360-20657-1-git-send-email-matt.redfearn@mips.com> <605f6a96-a843-085c-efc6-a2c0f2afd84a@mvista.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ABTtc+pdwF7KHXCz" Content-Disposition: inline In-Reply-To: <605f6a96-a843-085c-efc6-a2c0f2afd84a@mvista.com> Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Corey Minyard Cc: Matt Redfearn , Ralf Baechle , Matthew Fortune , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, "Jason A. Donenfeld" , Paul Burton Message-ID: <20171031234853.B8Zi4nEASEZG532PWtacuC2nfWquazhA5gNG3nfacTo@z> --ABTtc+pdwF7KHXCz Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 11, 2017 at 08:12:31AM -0500, Corey Minyard wrote: > On 10/11/2017 03:59 AM, Matt Redfearn wrote: > > Commit 9fef68686317b ("MIPS: Make SAVE_SOME more standard") made several > > changes to the order in which registers are saved in the SAVE_SOME > > macro, used by exception handlers to save the processor state. In > > particular, it removed the > > move k1, sp > > in the delay slot of the branch testing if the processor is already in > > kernel mode. This is replaced later in the macro by a > > move k0, sp > > When CONFIG_EVA is disabled, this instruction actually appears in the > > delay slot of the branch. However, when CONFIG_EVA is enabled, instead > > the RPS workaround of > > MFC0 k0, CP0_ENTRYHI > > appears in the delay slot. This results in k0 not containing the stack > > pointer, but some unrelated value, which is then saved to the kernel > > stack. On exit from the exception, this bogus value is restored to the > > stack pointer, resulting in an OOPS. > > > > Fix this by moving the save of SP in k0 explicitly in the delay slot of > > the branch, outside of the CONFIG_EVA section, restoring the expected > > instruction ordering when CONFIG_EVA is active. > > > > Fixes: 9fef68686317b ("MIPS: Make SAVE_SOME more standard") > > Signed-off-by: Matt Redfearn > > Reported-by: Vladimir Kondratiev >=20 > I looked this over pretty carefully and it looks correct to me.=C2=A0 It= =20 > makes no difference > in the instructions generated by the non-EVA case.=C2=A0 I shouldn't have= =20 > missed this :(. >=20 > Reviewed-by: Corey Minyard Yeh, having stared at it for a little while it looks correct to me too. Reviewed-by: James Hogan Cheers James --ABTtc+pdwF7KHXCz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEd80NauSabkiESfLYbAtpk944dnoFAln5C90ACgkQbAtpk944 dnoa+g//bueyNffOEKJETzj+ErDTSSO0WpbJRJKK0AfKoct54YFUbr37ErVGUb/L MkMtgyfqdm4uutAhCp90Jn70ZOEAlheb2MjbnHvp5oNJ7PgohJkzocc3x5xA2B3F YbuIaTmfUa1W93h3+YSmE0DYYN7uas+j6AFoGf9Q6KryRoKbrHwnxEy8vhLJGFvd 7szraNYk37S/nKTASAQmznNrAkjWeAbJ5qSvzPh0Ll3WDPGMPq6tAs+WoZrS1pmr 23GLs+Jc8y2LLlMFjRiid1majATC9kcljlXSC8diq9b8TopPRhRx2ciuiaLeK2P9 IkriDqu/313ADgi9/3UdJK/UBwz4nYbwo9z++Xv8DQzSH4RwDm/UDr9cJK1xBJm7 kZ2s8/z2i5KFne9kqEOs1AjqhRWQtt4P6AnDY3b75/109wQB6zk2m3RtezB8DBP3 qOhrCecCnnyk6RrenuQm9yXYAnH83GVVWUmN7z0mtAaeNZCcDFZckvGILM8evRvI A66/xSg3ACmOJbKS1XCtXwmKoLDdieKstmZCWSFmBXNHmzye4343RG6dZeWD3FvD hhaKWoTKl3VpKoyA3trnCulPhTrX6heuIJF+Jyah+0sZjOiCtlFDQN8J58k755XY mgb2xe9jiUw+qU6v4GMQ6Fuw3fh/PxLsTUAc7XZYFfI58HxB+0g= =/GEg -----END PGP SIGNATURE----- --ABTtc+pdwF7KHXCz--