From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32365 invoked by alias); 25 Jan 2018 01:48:38 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 32277 invoked by uid 89); 25 Jan 2018 01:48:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: vmicros1.altlinux.org Date: Thu, 25 Jan 2018 01:48:00 -0000 From: "Dmitry V. Levin" To: "H.J. Lu" Cc: Carlos O'Donell , Florian Weimer , "Senkevich, Andrew" , Andreas Schwab , GNU C Library Subject: Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563] Message-ID: <20180125014816.GA5754@altlinux.org> Mail-Followup-To: "H.J. Lu" , Carlos O'Donell , Florian Weimer , "Senkevich, Andrew" , Andreas Schwab , GNU C Library References: <20180121161557.GA31477@aurel32.net> <146fe611-dbc4-af4d-f737-194712daa835@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: X-SW-Source: 2018-01/txt/msg00779.txt.bz2 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2349 On Wed, Jan 24, 2018 at 05:09:39PM -0800, H.J. Lu wrote: > On Wed, Jan 24, 2018 at 4:32 PM, Carlos O'Donell wrot= e: > > On 01/24/2018 10:23 AM, Florian Weimer wrote: > >> On 01/24/2018 07:08 PM, H.J. Lu wrote: > >>> We opened a bug: > >>> > >>> https://sourceware.org/bugzilla/show_bug.cgi?id=3D22743 > >>> > >>> Any help to track down the root cause is appreciated. > >> > >> Doesn't the bug report clearly show the root cause? The offset of > >> priv.data.cleanup changed, and old binaries have an insufficiently > >> large stack allocation for the new offset. > >> > >> (Congratulations for tracking it down, by the way. I know that such > >> bugs are hard.) > >> > >> You need to add a symbol version for pthread_register_cancel. It's > >> too late for that now, so I recommend reverting the faulty commit. > > > > I have finished analyzing this and debugging the root cause myself, > > and I agree with Florian, we need to revert: > > > > commit f81ddabffd76ac9dd600b02adbf3e1dac4bb10ec > > commit cba595c350e52194e10c0006732e1991e3d0803b > > > > At a minimum. I am testing with them reverted locally. > > > > To be honest I'm surprised that this passed review and was checked > > in, because the __pthread_unwind_buf_t has only at most 4-bytes of > > space left before it is an ABI change. In the future please ping > > me if you have any doubts and I'll review. > > > > The addition of __sigset_t saved_mask moves pthread_unwind_buf's > > priv.data.cleanup forward by 124-bytes. The on-stack allocation of > > the pthread_cleanup_push's __pthread_unwind_buf_t is not that big > > and so __pthread_register_cancel writes to other structures which > > are allocated on the stack. > > > > You cannot expand struct pthread_unwind_buf because the on-stack > > allocated __pthread_unwind_buf_t is not large enough in existing > > applications. > > > > You *might* have used feature_1 to change between two different > > layouts of struct pthread_unwind_buf, but that will have to wait > > for 2.28. As Florian suggests though it is cleaner to version > > __pthread_register_cancel for x86 and the older version expects > > the smaller non-CET-enabled structure. >=20 > I will try to fix it by next Monday. I'm afraid by Monday it will be too late for 2.27 as we will get very little testing before the release. --=20 ldv --J/dobhs11T7y2rNN Content-Type: application/pgp-signature; name="signature.asc" Content-length: 801 -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaaTdgAAoJEAVFT+BVnCUILDEP/1GO6YtiU1HsOCCgRoLBTFt+ zNPnKE5tNdzpSaLlmc+DLd/rpnasmawrWNV+dQR0uB1korkZWibyR663F8Qp3Knl RCr/KtlTjCstt4aoJ47UEVFDLUmJslD+TS2pCVACAZKG2FJGKR/UcjJyGgRfmsDG 6gjNnCiNaeGf6qNjoxvO5cJtECpOfiXCPERTAVXXOgQoSj8ysQMSaWJc9ZDOMVS+ /qYfydzNPndxOFfzXQ2mLH3IWER8ODBB8NrVbl65gaBljpr2dGtaIWUZW3UAV63k 4noZP7wDrdKIKV0a2fkPRi83lEacSEs7SiqBHYeQtXh3HblclTtX7ZGRPD7q2Gt2 SPlJduRWIMkMk3tiHQr1B3XPD286RAR+oqrNR0876E5HAnP8QMGwA6ft0fUuftVE Flr/ymBcEFA12yNDW9mG+3+DqiNqd0aLHxnbTK+A+/jPNYiMO9TYvyaekB4s/cmT 6uWBLBWVladmp3YRy0RC3ljd8Le0utOBV0hjphnQw5RRclIRcS9RclXsTa4ft3eK qDNWqvv8oxgC4pu5bck08ibUCgfBSUmbTVs+h7Jq/ftSo4bF72wwal2JZ+JdQ1i/ u84sw/SISOF4ey28kyXtLf4Y8na5au1ZlywT6zSN/VvXOzX8lqA2lVSlMxIoh9fw jM4ICdnK7f3z0vh8K/z5 =xZmm -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN--