Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Aug 2014 17:02:19 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Svatopluk Kraus <onwahe@gmail.com>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: PMAP_LOCK_DESTROY() vs. vmspace UMA_ZONE_NOFREE
Message-ID:  <20140815140219.GU2737@kib.kiev.ua>
In-Reply-To: <CAFHCsPXLa2cZFBVSGm-e42p7oK5ZuQBwE5aNokuV2KrodKTSpA@mail.gmail.com>
References:  <CAFHCsPXLa2cZFBVSGm-e42p7oK5ZuQBwE5aNokuV2KrodKTSpA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140815140219.GU2737>