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
[-- Attachment #1 --]
On Fri, Aug 15, 2014 at 03:20:29PM +0200, Svatopluk Kraus wrote:
> Hi,
>
> 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.
>
> 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.
>
> The pmap_c_patch.txt is attached to solve it.
>
> IMHO, I think that definition of PMAP_LOCK_DESTROY() is misleading a little
> as PMAP_LOCK_DESTROY() cannot be used anywhere as long as UMA_ZONE_NOFREE
> flag is used.
>
> The pmap_all_patch.txt is attach to wipe PMAP_LOCK_DESTROY() out of source
> tree.
>
> Svata
> Index: sys/i386/i386/pmap.c
> ===================================================================
> --- sys/i386/i386/pmap.c (revision 270020)
> +++ sys/i386/i386/pmap.c (working copy)
> @@ -1755,10 +1755,8 @@
> */
> if (pmap->pm_pdir == NULL) {
> pmap->pm_pdir = (pd_entry_t *)kva_alloc(NBPTD);
> - if (pmap->pm_pdir == NULL) {
> - PMAP_LOCK_DESTROY(pmap);
> + if (pmap->pm_pdir == NULL)
> return (0);
> - }
> #ifdef PAE
> pmap->pm_pdpt = uma_zalloc(pdptzone, M_WAITOK | M_ZERO);
> KASSERT(((vm_offset_t)pmap->pm_pdpt &
> Index: sys/i386/xen/pmap.c
> ===================================================================
> --- sys/i386/xen/pmap.c (revision 270020)
> +++ sys/i386/xen/pmap.c (working copy)
> @@ -1459,7 +1459,6 @@
> if (pmap->pm_pdir == NULL) {
> pmap->pm_pdir = (pd_entry_t *)kva_alloc(NBPTD);
> if (pmap->pm_pdir == NULL) {
> - PMAP_LOCK_DESTROY(pmap);
> #ifdef HAMFISTED_LOCKING
> mtx_unlock(&createdelete_lock);
> #endif
> Index: sys/sparc64/sparc64/pmap.c
> ===================================================================
> --- sys/sparc64/sparc64/pmap.c (revision 270020)
> +++ sys/sparc64/sparc64/pmap.c (working copy)
> @@ -1211,11 +1211,9 @@
> */
> if (pm->pm_tsb == NULL) {
> pm->pm_tsb = (struct tte *)kva_alloc(TSB_BSIZE);
> - if (pm->pm_tsb == NULL) {
> - PMAP_LOCK_DESTROY(pm);
> + if (pm->pm_tsb == NULL)
> return (0);
> }
> - }
>
> /*
> * 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.
[-- Attachment #2 --]
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140815140219.GU2737>