Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4FE9721785
Date:   Mon, 9 Apr 2018 21:42:29 +0100
From:   James Hogan <jhogan@kernel.org>
To:     Sasha Levin <Alexander.Levin@microsoft.com>
Cc:     "stable@vger.kernel.org" <stable@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Paul Burton <paul.burton@imgtec.com>,
        "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
        Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH AUTOSEL for 4.9 173/293] MIPS: Handle tlbex-tlbp race
 condition
Message-ID: <20180409204229.GE17347@saruman>
References: <20180409002239.163177-1-alexander.levin@microsoft.com>
 <20180409002239.163177-173-alexander.levin@microsoft.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="0QFb0wBpEddLcDHQ"
Content-Disposition: inline
In-Reply-To: <20180409002239.163177-173-alexander.levin@microsoft.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--0QFb0wBpEddLcDHQ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 09, 2018 at 12:25:09AM +0000, Sasha Levin wrote:
> From: Paul Burton <paul.burton@imgtec.com>
>=20
> [ Upstream commit f39878cc5b09c75d35eaf52131e920b872e3feb4 ]
>=20
> In systems where there are multiple actors updating the TLB, the
> potential exists for a race condition wherein a CPU hits a TLB exception
> but by the time it reaches a TLBP instruction the affected TLB entry may
> have been replaced. This can happen if, for example, a CPU shares the
> TLB between hardware threads (VPs) within a core and one of them
> replaces the entry that another has just taken a TLB exception for.
>=20
> We handle this race in the case of the Hardware Table Walker (HTW) being
> the other actor already, but didn't take into account the potential for
> multiple threads racing. Include the code for aborting TLB exception
> handling in affected multi-threaded systems, those being the I6400 &
> I6500 CPUs which share TLB entries between VPs.
>=20
> In the case of using RiXi without dedicated exceptions we have never
> handled this race even for HTW. This patch adds WARN()s to these cases
> which ought never to be hit because all CPUs with either HTW or shared
> FTLB RAMs also include dedicated RiXi exceptions, but the WARN()s will
> ensure this is always the case.

=2E..

> +	/*
> +	 * If the CPU shares FTLB RAM with its siblings then our entry may be
> +	 * replaced at any time by a sibling performing a write to the FTLB.
> +	 */
> +	if (cpu_has_shared_ftlb_ram)

cpu_has_shared_ftlb_ram was only added in v4.13, commit e7bc8557428f
("MIPS: Add CPU shared FTLB feature detection"). To backport this patch
you'd need that one too at least (and I6500 support was also new in 4.13
so you'd also have to drop that case from the backport of that patch).

There may be other dependencies too, I don't know OTOH.

Cheers
James

--0QFb0wBpEddLcDHQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEd80NauSabkiESfLYbAtpk944dnoFAlrL0DUACgkQbAtpk944
dnqzGxAAnk8FHAtfIuBnHAWn4zo52YiO17tEzqjop4yu1MSgmlzilTMq1ebc1ziz
raCU6EBUPfvHxPsI+hFZs1IzyyGwNCCuvNdXH5L99FK/fku1sLzMm1wTP3cCiVaF
5G8ysaeZedI+QA5DkyV3O32otpmmTCEauog6it0nNSuazQ4vGHlEMey0HfVPFTal
ssGDCUGrigjsg2zyHZ50UzWjpcxXLHwR6xtSiipi1s9K2tRp07Ivj4N2cMO/qNqW
/qEY7lwEwj1o+uKO1lVzwF/r9H6To0C+okmA3D/5E2YH4ZfL/w1RjBcZcxC2iabX
V5HS5A21j9kx5gnPPn3/ynJ/wigisOFZk8cPJehwsF2NYTLgWxFD+nOislhi5n3m
N6oCW2+g6E4qJCXWeJazJ2ooN/LZ4r4qEk/0EKzq+Bc8nYbr1mS1eTlVxC5/pAdZ
qAZWAvWNh3NCFqTWinue5o0903ddIdOZ3Ovy1/eiyO0Ln8pyZhdrpYxZdurAujL+
3fQxh/BwkSmtx6leX9brwE4QJNEzngmjWcqAVM46OHXGrTgLDr4Njt9kpHFItrKa
OIoB+Wp6iXFy9I4/XIcZuV+SUaIhv6C2LVxxMC9Vy7JVGoVA9Pvp2q3Zssa6fYob
TXwYhAIbdCtTjvtxlVT67GPvYMEoZSXxgR2o0AOg9z2+mf1UGHM=
=UWpd
-----END PGP SIGNATURE-----

--0QFb0wBpEddLcDHQ--