From owner-freebsd-toolchain@FreeBSD.ORG Tue Jan 8 15:00:35 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 112AC1CA; Tue, 8 Jan 2013 15:00:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7ED3D74F; Tue, 8 Jan 2013 15:00:34 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id r08F0PSP097265; Tue, 8 Jan 2013 17:00:25 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r08F0PSP097265 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id r08F0OwQ097264; Tue, 8 Jan 2013 17:00:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Jan 2013 17:00:24 +0200 From: Konstantin Belousov To: Alfred Perlstein Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <20130108150024.GE82219@kib.kiev.ua> References: <20130107182235.GA65279@kib.kiev.ua> <50EB3319.6060303@mu.org> <20130108000840.GA82219@kib.kiev.ua> <50EBBAFC.9070803@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="prKJgtdAmn5IQEeG" Content-Disposition: inline In-Reply-To: <50EBBAFC.9070803@mu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 15:00:35 -0000 --prKJgtdAmn5IQEeG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 08, 2013 at 01:21:48AM -0500, Alfred Perlstein wrote: > On 1/7/13 7:08 PM, Konstantin Belousov wrote: > > On Mon, Jan 07, 2013 at 03:42:01PM -0500, Alfred Perlstein wrote: > >> On 1/7/13 1:22 PM, Konstantin Belousov wrote: > >>> Below is the forward of the patch for which I failed to obtain a priv= ate > >>> review. Might be, the list generates more responses. > >> Very cool. > >> > >> Sorry for being rusty here, but is it safe to call fuword in the middle > >> of issignal()? > >> > >> The reason I ask is because it looks like proc lock is required for th= is > >> block, and I forget it fuword(9) can fault. > >> > >> If fuword(9) can fault then I don't think you can do this. > >> > >> You'll need to use something like fuswintr(9) or wire the page down > >> using vslock(9) or something. > >> > >> I am probably missing something? > > No, you are completely right. This is a serious bug. Thank you. > > > > I was careful to code the td_sigblock_val prefetch etc, but failed > > to do the update properly. There is no reason to execute the update > > in the issignal() at all, the setting of the pending bit can be postpon= ed > > to the moment after the postsig() loop was executed. > > > > I uploaded the updated but not yet tested patch at > > http://people.freebsd.org/~kib/misc/rtld-sigblock.1.patch >=20 > This new patch looks like it may have issues with PSTOP. >=20 > there is a lot of code in issignal() that is missed when this code is in= =20 > place, I have not audited the effect of this, are you sure this is what= =20 > will work for the majority of cases? What exactly you are concerned with ? Note that fastblock_mask manipulations right before setting of TDP_FAST_SIGPENDING is to disallow the postponing of the delivery of (potentially) synchronous signals caused by traps, as well as SIGKILL/SIGSTOP. >=20 > Honestly, if I were coding it for correctness I would vslock the pages=20 > (or otherwise wire them in) and let issignal() behave normally and not=20 > early exit from it. vslock() is racy, causes user address space fragmentation and was simply impossibly to use correctly until very recent. --prKJgtdAmn5IQEeG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ7DSHAAoJEJDCuSvBvK1BRvwP/01DeP1jOWHj4dsGCavZPXKh D3yI6BYAaPxiQihncwRQg8FO/eSoXlAx16wRbrZz5aj7FUq6taOEJ5mcf6jkp1mr IM47VZVQnYWunDP7rrLP4EsurIPfn5OVyazx/hXQO4lD+6JFpWczGP5FQUjJDWK4 2TdMvYa/Q3Wfj73xzVuvtKncrwEx3klT0LOq+fPvUBP/I2AWHI/Wh2+yZVcHD3PL 9mihrB5JuK+h6chbKYmNGrNSoAZQqNBXDHWoGtSfIlPr1jfzzl+Pdq9Z0cOJWYyY qZOs5GksPHbwNWQc2qJrKgLA/ckZaZF8CLAlxWpspizsBoqztQGE9lVPQGP9rVOz J2PbUzPZsfUNzjHvsT1mIoicC/rl1Q98IgKc521npXgCKza9nzQXOxi4rCNZ4Uoo wueGh/y+OP75cTSn88/QZS46pM3gXi+G2Udx46hRJO0rrCYKocGlEG2nHRtULE8S 45VwUciiswuVVwWoKw9w93MCIzCtvX0Hv0GaRoJrz8lNJ9Dzo/uqGrxXkUdv8BbT Z2rFwRoeddXi8j8cmKmAg/bSfooKJAocndPSleaakmSG54oijAxSt3KIqf4QJrw4 ZuTmY240QUZaBbQkkqUltlEL06dF4G+vZ1pvKcZ5KCtr4T9ICp5VCVacQMcsYQ9Q 7/t9PLEpX6cmyozwydb9 =5W7k -----END PGP SIGNATURE----- --prKJgtdAmn5IQEeG--