From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 14:02:30 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D6C644B for ; Fri, 15 Aug 2014 14:02:30 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98BF0221F for ; Fri, 15 Aug 2014 14:02:29 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7FE2Jeq011615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Aug 2014 17:02:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7FE2Jeq011615 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7FE2J0u011614; Fri, 15 Aug 2014 17:02:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 Aug 2014 17:02:19 +0300 From: Konstantin Belousov To: Svatopluk Kraus Subject: Re: PMAP_LOCK_DESTROY() vs. vmspace UMA_ZONE_NOFREE Message-ID: <20140815140219.GU2737@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KJvkvZqQCzHgjKcr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 14:02:30 -0000 --KJvkvZqQCzHgjKcr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 15, 2014 at 03:20:29PM +0200, Svatopluk Kraus wrote: > Hi, >=20 > I was playing with ports/benchmarks/forkbomb while testing my and Michal's > armv6 pmap based on i386 one when I found - IMHO - sketelot in the closet. >=20 > i386, xen, and sparc64 pmaps call PMAP_LOCK_DESTROY() in pmap_pinit() if > some allocation failed. As vmspace (struct pmap is part of it) uma zone is > created with UMA_ZONE_NOFREE flag and PMAP_LOCK_INIT() is called from > vmspace_zinit() initiator, PMAP_LOCK_DESTROY() should be called from > nowhere. >=20 > The pmap_c_patch.txt is attached to solve it. >=20 > IMHO, I think that definition of PMAP_LOCK_DESTROY() is misleading a litt= le > as PMAP_LOCK_DESTROY() cannot be used anywhere as long as UMA_ZONE_NOFREE > flag is used. >=20 > The pmap_all_patch.txt is attach to wipe PMAP_LOCK_DESTROY() out of source > tree. >=20 > Svata > Index: sys/i386/i386/pmap.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/i386/i386/pmap.c (revision 270020) > +++ sys/i386/i386/pmap.c (working copy) > @@ -1755,10 +1755,8 @@ > */ > if (pmap->pm_pdir =3D=3D NULL) { > pmap->pm_pdir =3D (pd_entry_t *)kva_alloc(NBPTD); > - if (pmap->pm_pdir =3D=3D NULL) { > - PMAP_LOCK_DESTROY(pmap); > + if (pmap->pm_pdir =3D=3D NULL) > return (0); > - } > #ifdef PAE > pmap->pm_pdpt =3D uma_zalloc(pdptzone, M_WAITOK | M_ZERO); > KASSERT(((vm_offset_t)pmap->pm_pdpt & > Index: sys/i386/xen/pmap.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/i386/xen/pmap.c (revision 270020) > +++ sys/i386/xen/pmap.c (working copy) > @@ -1459,7 +1459,6 @@ > if (pmap->pm_pdir =3D=3D NULL) { > pmap->pm_pdir =3D (pd_entry_t *)kva_alloc(NBPTD); > if (pmap->pm_pdir =3D=3D NULL) { > - PMAP_LOCK_DESTROY(pmap); > #ifdef HAMFISTED_LOCKING > mtx_unlock(&createdelete_lock); > #endif > Index: sys/sparc64/sparc64/pmap.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/sparc64/sparc64/pmap.c (revision 270020) > +++ sys/sparc64/sparc64/pmap.c (working copy) > @@ -1211,11 +1211,9 @@ > */ > if (pm->pm_tsb =3D=3D NULL) { > pm->pm_tsb =3D (struct tte *)kva_alloc(TSB_BSIZE); > - if (pm->pm_tsb =3D=3D NULL) { > - PMAP_LOCK_DESTROY(pm); > + if (pm->pm_tsb =3D=3D NULL) > return (0); > } > - } > =20 > /* > * Allocate an object for it. Yes, I think this is result of incomplete r254667. Still, I prefer to keep the PMAP_LOCK_DESTROY() macro around. --KJvkvZqQCzHgjKcr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT7hLrAAoJEJDCuSvBvK1BozcP/3BY1eiPVKmRjaLHJyOcV2Mt toCs/a3MtUMnCu1xTs4eV0T+L7cEZNoL14gqk6TuIzw1rf2o9+6Dfll1ppBCmiZ8 uYvrKmgXs506wLw5Ufi5AtB00HOES3C7KrDih6TJ61xqemfJNnKbpoSljLq4hrJj PYLzMhqFFQFTHS8zsQGE4XkV47UUy4sWqwpVWo9TyWxumAyy7faU3ukHlp7oJoUZ FbgZcDzr1Cpp8snZ6Udn0g8LuPqQaiZbV0dl57911MoRJMari+uRgOX98HtsgCxi 4Wmb+Bf2cUIdNd2zDS/UQB3NqRl3blqbnLO3NV52vicrBB8j36C+KGrQ5RSPWkht sIi+bnzq2MXZkFd2oQsUO8n4SUuNZ3ZzinP/6NwlEjACBgshkQU8Z+GbRvGr/HvE M9SF3HKx9oIN1bHKpO3sSUC53kx/uVgEjckmF8VzBGDOeX6+zwaRmIZb48sHfQDd 132ILaTKhoymQ+B3Nm2yhzwBPHRo0/Daj9RhV4HHQxxgd5DFbrMzhi4XwTp5lm7x nXwQfevxcMNZ8fbjtK0d6me1ULiaJF4CeBQrzO6SwqG70hF3+7LC4rV7YSBa78fp 5kQ0cuUJ1ot0lDu9RocbPzsVnx5MHAsysPkIh8A/IJnOSQm3I72yHhIzYg6dNRA/ 5ahRvbfprMjBcRnFHrc7 =L7Co -----END PGP SIGNATURE----- --KJvkvZqQCzHgjKcr--