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;
Date:   Mon, 14 May 2018 23:37:16 +0100
From:   James Hogan <jhogan@kernel.org>
To:     "Maciej W. Rozycki" <macro@mips.com>
Cc:     Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
        linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR
 accesses to o32 FGRs
Message-ID: <20180514223715.GE29541@jamesdev>
References: <alpine.DEB.2.00.1805141537210.10896@tp.orcam.me.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="BQPnanjtCNWHyqYD"
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1805141537210.10896@tp.orcam.me.uk>
User-Agent: Mutt/1.9.5 (2018-04-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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

On Mon, May 14, 2018 at 04:49:43PM +0100, Maciej W. Rozycki wrote:
> Check the TIF_32BIT_FPREGS task setting of the tracee rather than the=20
> tracer in determining the layout of floating-point general registers in=
=20
> the floating-point context, correcting access to odd-numbered registers=
=20
> for o32 tracees where the setting disagrees between the two processes.
>=20
> Cc: stable@vger.kernel.org # 3.14+
> Fixes: 597ce1723e0f ("MIPS: Support for 64-bit FP with O32 binaries")
> Signed-off-by: Maciej W. Rozycki <macro@mips.com>
> ---
> Hi,
>=20
>  These are not the usual requests used by GDB to access the floating-poin=
t=20
> context, which is likely why it went unnoticed so long.  They are only=20
> used as a fallback in the case where PTRACE_GETFPREGS and PTRACE_SETFPREG=
S=20
> requests are not supported, i.e. with ancient kernels.
>=20
>  However to verify an unrelated GDB bug fix I have tweaked GDB to always=
=20
> use PTRACE_PEEKUSR and PTRACE_POKEUSR, and then discovered this issue in=
=20
> native GDB regression testing, as it showed regressions from corrupt FGR=
=20
> contents across numerous tests compared to the usual results.  This fix=
=20
> removed those regressions then.
>=20
>  Not being typically used does not mean we ought to keep the interface=20
> broken.  Therefore please apply.

Looks good. Applied to fixes branch for 4.17.

Thanks
James

--BQPnanjtCNWHyqYD
Content-Type: application/pgp-signature; name="signature.asc"

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

iHUEARYIAB0WIQS7lRNBWUYtqfDOVL41zuSGKxAj8gUCWvoPmgAKCRA1zuSGKxAj
8vHgAQCWxOnS4xlCHH+ctDoJS88qeXWE6ojQ4iM0LlzCyfNKrAEAo6VvdB1DEWg1
tBq1rCXSUbUnkg+qpV7h9T1CG5N1Cgc=
=df5g
-----END PGP SIGNATURE-----

--BQPnanjtCNWHyqYD--