Date: Tue, 8 Jan 2013 17:00:24 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alfred Perlstein <bright@mu.org> Cc: arch@freebsd.org, toolchain@freebsd.org Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <20130108150024.GE82219@kib.kiev.ua> In-Reply-To: <50EBBAFC.9070803@mu.org> References: <20130107182235.GA65279@kib.kiev.ua> <50EB3319.6060303@mu.org> <20130108000840.GA82219@kib.kiev.ua> <50EBBAFC.9070803@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130108150024.GE82219>