NetBSD Problem Report #53173

From www@NetBSD.org  Tue Apr 10 18:33:40 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id CA7987A154
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 10 Apr 2018 18:33:39 +0000 (UTC)
Message-Id: <20180410183338.DA11B7A212@mollari.NetBSD.org>
Date: Tue, 10 Apr 2018 18:33:38 +0000 (UTC)
From: bsiegert@NetBSD.org
Reply-To: bsiegert@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: (earmv7hf) "go test net/http" locks up the machine
X-Send-Pr-Version: www-1.0

>Number:         53173
>Notify-List:    gson@gson.org
>Category:       port-arm
>Synopsis:       (earmv7hf) "go test net/http" locks up the machine
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    port-arm-maintainer
>State:          feedback
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 10 18:35:00 +0000 2018
>Closed-Date:    
>Last-Modified:  Fri Apr 19 16:15:01 +0000 2019
>Originator:     Benny Siegert
>Release:        NetBSD 8.99.14, pkgsrc 2018Q1
>Organization:
The NetBSD Foundation
>Environment:
NetBSD (redacted) 8.99.14 NetBSD 8.99.14 (SUNXI) #0: Sun Mar 18 13:18:39 UTC 2018 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/SUNXI evbarm
go version go1.10 netbsd/arm
>Description:
I am running a continuous NetBSD builder on this OrangePi Plus 2E and noticed lockups of the system during tests. They tend to occur during the net/http test suite.

Symptom: the console stops updating or accepting input. The system gets warm, presumably the CPU is busy spinlocking.
>How-To-Repeat:
1. install lang/go from pkgsrc
2. Run "go test net/http", you may have to repeat a few times.
>Fix:

>Release-Note:

>Audit-Trail:
From: Benny Siegert <bsiegert@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Tue, 10 Apr 2018 19:56:16 +0000

 It looks like the crash occurs in the test named
 TestServerDuplicateBackgroundRead, defined here:
 https://golang.org/src/net/http/serve_test.go#L5592

 You can get more verbose output with "go test -v net/http".

From: Andreas Gustafsson <gson@gson.org>
To: bsiegert@NetBSD.org, gnats-bugs@NetBSD.org
Cc: Christos Zoulas <christos@zoulas.com>, Martin Husemann <martin@duskware.de>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Wed, 9 May 2018 11:35:35 +0300

 Hello Benny,

 I believe this kernel hang has been fixed in -current by
 src/sys/kern/kern_lwp.c 1.192.  Can you confirm this?

 I have requested a pullup to -8 (#805), but it has been stalled due
 to claims that it "breaks golang".  If you can help either confirm or
 refute those claims, that would also be helpful.
 -- 
 Andreas Gustafsson, gson@gson.org

State-Changed-From-To: open->feedback
State-Changed-By: gson@NetBSD.org
State-Changed-When: Wed, 09 May 2018 08:44:07 +0000
State-Changed-Why:
feedback requested


From: Benny Siegert <bsiegert@netbsd.org>
To: Andreas Gustafsson <gson@gson.org>
Cc: gnats-bugs@netbsd.org, Christos Zoulas <christos@zoulas.com>, 
	Martin Husemann <martin@duskware.de>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Wed, 09 May 2018 20:43:50 +0000

 On Wed, May 9, 2018 at 10:35 AM Andreas Gustafsson <gson@gson.org> wrote:
 > I believe this kernel hang has been fixed in -current by
 > src/sys/kern/kern_lwp.c 1.192.  Can you confirm this?

 I'll be able to confirm next week when I can try it on the real hardware,
 is that okay?

 > I have requested a pullup to -8 (#805), but it has been stalled due
 > to claims that it "breaks golang".  If you can help either confirm or
 > refute those claims, that would also be helpful.

 I remember 1.191 was supposed to fix hanging Go processes, yes. This
 occurred on the amd64 builders though. You should be able to confirm this
 by extracting the Go 1.10.1 tarball somewhere and then doing "cd src &&
 all.bash" on a system with 1.192 on it.

 -- 
 Benny

From: Andreas Gustafsson <gson@gson.org>
To: Benny Siegert <bsiegert@netbsd.org>
Cc: gnats-bugs@netbsd.org,
    Christos Zoulas <christos@zoulas.com>,
    Martin Husemann <martin@duskware.de>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Thu, 10 May 2018 11:50:52 +0300

 Benny Siegert wrote:
 > On Wed, May 9, 2018 at 10:35 AM Andreas Gustafsson <gson@gson.org> wrote:
 > > I believe this kernel hang has been fixed in -current by
 > > src/sys/kern/kern_lwp.c 1.192.  Can you confirm this?
 > 
 > I'll be able to confirm next week when I can try it on the real hardware,
 > is that okay?

 I think so - as far as I'm concerned the main purpose of checking this
 is just to allow the PR to be closed (or rather, switched to the
 pending-pullups state).  I have not heard anything from releng to
 suggest that the outcome could affect their stance regarding the
 pullup request (Martin please correct me if I'm wrong).

 > > I have requested a pullup to -8 (#805), but it has been stalled due
 > > to claims that it "breaks golang".  If you can help either confirm or
 > > refute those claims, that would also be helpful.
 > 
 > I remember 1.191 was supposed to fix hanging Go processes, yes. This
 > occurred on the amd64 builders though. You should be able to confirm this
 > by extracting the Go 1.10.1 tarball somewhere and then doing "cd src &&
 > all.bash" on a system with 1.192 on it.

 I will follow up on this part separately in the context of releng
 ticket #805.
 -- 
 Andreas Gustafsson, gson@gson.org

From: Martin Husemann <martin@duskware.de>
To: Andreas Gustafsson <gson@gson.org>
Cc: Benny Siegert <bsiegert@netbsd.org>, gnats-bugs@netbsd.org,
	Christos Zoulas <christos@zoulas.com>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the
 machine
Date: Thu, 10 May 2018 11:27:28 +0200

 On Thu, May 10, 2018 at 11:50:52AM +0300, Andreas Gustafsson wrote:
 > I think so - as far as I'm concerned the main purpose of checking this
 > is just to allow the PR to be closed (or rather, switched to the
 > pending-pullups state).  I have not heard anything from releng to
 > suggest that the outcome could affect their stance regarding the
 > pullup request (Martin please correct me if I'm wrong).

 Currently there is no clear picture which state is better, as soon
 as that gets clear, we should make sure that -8 is in the best state
 possible.

 We want all (default) tests working and a well supported golang when
 8.0 comes out. (And a pony, before we go on to world domination and the
 desktop market)

 Martin

From: Benny Siegert <bsiegert@netbsd.org>
To: Martin Husemann <martin@duskware.de>
Cc: Andreas Gustafsson <gson@gson.org>, gnats-bugs@netbsd.org, 
	Christos Zoulas <christos@zoulas.com>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Tue, 15 May 2018 21:10:59 +0200

 So with a -current kernel from today (2018-05-15), "go test net/http" in Go
 1.10 still locks up the machine, reproducibly.

From: Andreas Gustafsson <gson@gson.org>
To: Benny Siegert <bsiegert@netbsd.org>
Cc: Martin Husemann <martin@duskware.de>,
    gnats-bugs@netbsd.org,
    Christos Zoulas <christos@zoulas.com>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Wed, 16 May 2018 07:47:42 +0300

 Benny Siegert wrote:
 > So with a -current kernel from today (2018-05-15), "go test net/http" in Go
 > 1.10 still locks up the machine, reproducibly.

 I'm sorry to hear that.  This is still on the Orange Pi
 uniprocessor system, right?

 Could you give step-by-step instructions for how to reproduce this on
 a freshly installed -current, including the download and install of Go?
 -- 
 Andreas Gustafsson, gson@gson.org

From: Benny Siegert <bsiegert@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: port-arm-maintainer@netbsd.org, gnats-admin@netbsd.org, 
	netbsd-bugs@netbsd.org, Andreas Gustafsson <gson@gson.org>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Sun, 8 Jul 2018 13:44:37 +0200

 Sorry for not following up earlier on this.

 >  Benny Siegert wrote:
 >  > So with a -current kernel from today (2018-05-15), "go test net/http" in Go
 >  > 1.10 still locks up the machine, reproducibly.
 >
 >  I'm sorry to hear that.  This is still on the Orange Pi
 >  uniprocessor system, right?

 Yes, though it is a quad-core (4 CPUs).

 >  Could you give step-by-step instructions for how to reproduce this on
 >  a freshly installed -current, including the download and install of Go?

 cd /usr/pkgsrc/lang/go
 make package-install
 go test net/http

 -- 
 Benny

From: Andreas Gustafsson <gson@gson.org>
To: Benny Siegert <bsiegert@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Mon, 9 Jul 2018 18:53:50 +0300

 Benny Siegert wrote:
 > cd /usr/pkgsrc/lang/go
 > make package-install
 > go test net/http

 I don't have an Orange Pi, so I tried this on the closest
 thing I have, a Raspberry Pi 3 model B, by installing
 -current from 2018.07.08.14.46.23 and pkgsrc from
 ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz as
 of the same same day, but was unable to reproduce the
 problem - the test passed:

 ok     net/http          94.189s

 -- 
 Andreas Gustafsson, gson@gson.org

From: Andreas Gustafsson <gson@gson.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Tue, 7 Aug 2018 17:04:30 +0300

 I have now run the net/http test case 100 times in a row on my
 Raspberry Pi 3 model B, using -current from 2018.07.08.14.46.23 and
 pkgsrc from ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz as
 of today, and I'm still unable to make the machine lock up.  Three out
 of the 100 runs reported "--- FAIL: TestTimeoutHandlerRace", and the
 other 97 passed.

 These are the commands I ran:

 cd /usr/pkgsrc/lang/go
 make package-install
 seq 100 | while read i
 do 
   GOCACHE=off /usr/pkg/go/bin/go test net/http
 done

 -- 
 Andreas Gustafsson, gson@gson.org

From: Benny Siegert <bsiegert@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-arm/53173
Date: Mon, 21 Jan 2019 14:41:03 +0100

 Sorry for the radio silence. This still locks up the system
 reproducibly on my Orange Pi with go-1.11.3 from pkgsrc. Entering "go
 test net/http" locks up the system without *any* kernel messages.

 The kernel is
 NetBSD 8.99.24 (SUNXI) #0: Sat Aug 18 06:52:57 2018

 I'll try a newer kernel tomorrow.

 -- 
 Benny

From: Benny Siegert <bsiegert@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-arm/53173
Date: Mon, 21 Jan 2019 14:52:40 +0100

 On Mon, Jan 21, 2019 at 2:41 PM Benny Siegert <bsiegert@gmail.com> wrote:
 >
 > Sorry for the radio silence. This still locks up the system
 > reproducibly on my Orange Pi with go-1.11.3 from pkgsrc. Entering "go
 > test net/http" locks up the system without *any* kernel messages.
 >
 > The kernel is
 > NetBSD 8.99.24 (SUNXI) #0: Sat Aug 18 06:52:57 2018

 I think I have a lead:

 The machine has an urtwn Wi-Fi dongle. If I pull out the dongle before
 running the test, it succeeds (most of the time), as you describe. So
 it sounds like a bug in the urtwn driver?

 -- 
 Benny

State-Changed-From-To: feedback->open
State-Changed-By: bsiegert@NetBSD.org
State-Changed-When: Mon, 21 Jan 2019 13:55:45 +0000
State-Changed-Why:
Feedback provided


From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-arm/53173
Date: Mon, 21 Jan 2019 14:59:58 +0100

 On Mon, Jan 21, 2019 at 01:55:00PM +0000, Benny Siegert wrote:
 >  The machine has an urtwn Wi-Fi dongle. If I pull out the dongle before
 >  running the test, it succeeds (most of the time), as you describe. So
 >  it sounds like a bug in the urtwn driver?

 Can you try with the on-board interface? Maybe it is network connectivity
 that makes the difference (instead of the concrete driver).

 Martin

State-Changed-From-To: open->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Tue, 05 Feb 2019 22:02:55 +0000
State-Changed-Why:
Duplicate kern/53922


State-Changed-From-To: closed->feedback
State-Changed-By: bsiegert@NetBSD.org
State-Changed-When: Sat, 16 Feb 2019 16:03:54 +0000
State-Changed-Why:
This is a different bug than 53922.


From: Manuel Bouyer <bouyer@antioche.eu.org>
To: bsiegert@NetBSD.org
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the
 machine
Date: Fri, 19 Apr 2019 18:12:23 +0200

 --cWoXeonUoKmBZSoM
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline

 hello,
 can you see if the attached patch fixes the issue for you ?
 I had similar lock up on network load, and it should fix it.

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

 --cWoXeonUoKmBZSoM
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename=diff

 Index: arm32/pmap.c
 ===================================================================
 RCS file: /cvsroot/src/sys/arch/arm/arm32/pmap.c,v
 retrieving revision 1.371
 diff -u -p -u -r1.371 pmap.c
 --- arm32/pmap.c	28 Oct 2018 14:59:17 -0000	1.371
 +++ arm32/pmap.c	19 Apr 2019 15:55:30 -0000
 @@ -217,6 +217,10 @@

  #include <arm/locore.h>

 +#ifdef DDB
 +#include <arm/db_machdep.h>
 +#endif
 +
  __KERNEL_RCSID(0, "$NetBSD: pmap.c,v 1.371 2018/10/28 14:59:17 skrll Exp $");

  //#define PMAP_DEBUG
 @@ -516,7 +520,8 @@ static size_t cnptes;
  #endif
  vaddr_t memhook;			/* used by mem.c & others */
  kmutex_t memlock __cacheline_aligned;	/* used by mem.c & others */
 -kmutex_t pmap_lock __cacheline_aligned;
 +kmutex_t pmap_pg_lock __cacheline_aligned;
 +kmutex_t kpm_lock __cacheline_aligned;
  extern void *msgbufaddr;
  int pmap_kmpages;
  /*
 @@ -538,9 +543,14 @@ vaddr_t pmap_directlimit;
  static inline void
  pmap_acquire_pmap_lock(pmap_t pm)
  {
 +#if defined(MULTIPROCESSOR) && defined(DDB)
 +	if (__predict_false(db_onproc != NULL))
 +		return;
 +#endif
 +	
  	if (pm == pmap_kernel()) {
  #ifdef MULTIPROCESSOR
 -		KERNEL_LOCK(1, NULL);
 +		mutex_enter(&kpm_lock);
  #endif
  	} else {
  		mutex_enter(pm->pm_lock);
 @@ -550,9 +560,13 @@ pmap_acquire_pmap_lock(pmap_t pm)
  static inline void
  pmap_release_pmap_lock(pmap_t pm)
  {
 +#if defined(MULTIPROCESSOR) && defined(DDB)
 +	if (__predict_false(db_onproc != NULL))
 +		return;
 +#endif
  	if (pm == pmap_kernel()) {
  #ifdef MULTIPROCESSOR
 -		KERNEL_UNLOCK_ONE(NULL);
 +		mutex_exit(&kpm_lock);
  #endif
  	} else {
  		mutex_exit(pm->pm_lock);
 @@ -562,20 +576,20 @@ pmap_release_pmap_lock(pmap_t pm)
  static inline void
  pmap_acquire_page_lock(struct vm_page_md *md)
  {
 -	mutex_enter(&pmap_lock);
 +	mutex_enter(&pmap_pg_lock);
  }

  static inline void
  pmap_release_page_lock(struct vm_page_md *md)
  {
 -	mutex_exit(&pmap_lock);
 +	mutex_exit(&pmap_pg_lock);
  }

  #ifdef DIAGNOSTIC
  static inline int
  pmap_page_locked_p(struct vm_page_md *md)
  {
 -	return mutex_owned(&pmap_lock);
 +	return mutex_owned(&pmap_pg_lock);
  }
  #endif

 @@ -3057,6 +3071,10 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
  #else
  	const bool vector_page_p = (va == vector_page);
  #endif
 +	struct pmap_page *pp = pmap_pv_tracked(pa);
 +	struct pv_entry *new_pv = NULL;
 +	struct pv_entry *old_pv = NULL;
 +	int error = 0;

  	UVMHIST_FUNC(__func__); UVMHIST_CALLED(maphist);

 @@ -3072,6 +3090,12 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
  	 * test for a managed page by checking pg != NULL.
  	 */
  	pg = pmap_initialized ? PHYS_TO_VM_PAGE(pa) : NULL;
 +	/*
 +	 * if we may need a new pv entry allocate if now, as we can't do it
 +	 * with the kernel_pmap locked
 +	 */
 +	if (pg || pp)
 +		new_pv = pool_get(&pmap_pv_pool, PR_NOWAIT);

  	nflags = 0;
  	if (prot & VM_PROT_WRITE)
 @@ -3095,7 +3119,8 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
  	if (l2b == NULL) {
  		if (flags & PMAP_CANFAIL) {
  			pmap_release_pmap_lock(pm);
 -			return (ENOMEM);
 +			error = ENOMEM;
 +			goto free_pv;
  		}
  		panic("pmap_enter: failed to allocate L2 bucket");
  	}
 @@ -3118,8 +3143,6 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
  	} else
  		opg = NULL;

 -	struct pmap_page *pp = pmap_pv_tracked(pa);
 -
  	if (pg || pp) {
  		KASSERT((pg != NULL) != (pp != NULL));
  		struct vm_page_md *md = (pg != NULL) ? VM_PAGE_TO_MD(pg) :
 @@ -3228,9 +3251,10 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
  				}
  #endif
  			} else {
 -				pmap_release_page_lock(md);
 -				pv = pool_get(&pmap_pv_pool, PR_NOWAIT);
 +				pv = new_pv;
 +				new_pv = NULL;
  				if (pv == NULL) {
 +					pmap_release_page_lock(md);
  					pmap_release_pmap_lock(pm);
  					if ((flags & PMAP_CANFAIL) == 0)
  						panic("pmap_enter: "
 @@ -3241,7 +3265,6 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
  					    0, 0, 0, 0);
  					return (ENOMEM);
  				}
 -				pmap_acquire_page_lock(md);
  			}

  			pmap_enter_pv(md, pa, pv, pm, va, nflags);
 @@ -3278,9 +3301,9 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
  			paddr_t opa = VM_PAGE_TO_PHYS(opg);

  			pmap_acquire_page_lock(omd);
 -			struct pv_entry *pv = pmap_remove_pv(omd, opa, pm, va);
 +			old_pv = pmap_remove_pv(omd, opa, pm, va);
  			pmap_vac_me_harder(omd, opa, pm, 0);
 -			oflags = pv->pv_flags;
 +			oflags = old_pv->pv_flags;
  			pmap_release_page_lock(omd);

  #ifdef PMAP_CACHE_VIVT
 @@ -3288,7 +3311,6 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
  				pmap_cache_wbinv_page(pm, va, true, oflags);
  			}
  #endif
 -			pool_put(&pmap_pv_pool, pv);
  		}
  	}

 @@ -3390,7 +3412,13 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_

  	pmap_release_pmap_lock(pm);

 -	return (0);
 +
 +	if (old_pv)
 +		pool_put(&pmap_pv_pool, old_pv);
 +free_pv:
 +	if (new_pv)
 +		pool_put(&pmap_pv_pool, new_pv);
 +	return (error);
  }

  /*
 @@ -3425,6 +3453,7 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
  	/*
  	 * we lock in the pmap => pv_head direction
  	 */
 +
  	pmap_acquire_pmap_lock(pm);

  #ifndef ARM_MMU_EXTENDED
 @@ -3463,6 +3492,7 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
  		for (;sva < next_bucket;
  		     sva += PAGE_SIZE, ptep += PAGE_SIZE / L2_S_SIZE) {
  			pt_entry_t opte = *ptep;
 +			struct pv_entry *opv = NULL;

  			if (opte == 0) {
  				/* Nothing here, move along */
 @@ -3480,17 +3510,15 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
  			 */
  			if (pg != NULL) {
  				struct vm_page_md *md = VM_PAGE_TO_MD(pg);
 -				struct pv_entry *pv;

  				pmap_acquire_page_lock(md);
 -				pv = pmap_remove_pv(md, pa, pm, sva);
 +				opv = pmap_remove_pv(md, pa, pm, sva);
  				pmap_vac_me_harder(md, pa, pm, 0);
  				pmap_release_page_lock(md);
 -				if (pv != NULL) {
 +				if (opv != NULL) {
  					if (pm->pm_remove_all == false) {
 -						flags = pv->pv_flags;
 +						flags = opv->pv_flags;
  					}
 -					pool_put(&pmap_pv_pool, pv);
  				}
  			}
  			mappings += PAGE_SIZE / L2_S_SIZE;
 @@ -3503,7 +3531,7 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
  				 */
  				l2pte_reset(ptep);
  				PTE_SYNC_CURRENT(pm, ptep);
 -				continue;
 +				goto free_opv;
  			}

  #ifdef ARM_MMU_EXTENDED
 @@ -3545,6 +3573,12 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
  				}
  			}
  #endif
 +free_opv:
 +			if (opv) {
 +				pmap_release_pmap_lock(pm);
 +				pool_put(&pmap_pv_pool, opv);
 +				pmap_acquire_pmap_lock(pm);
 +			}
  		}

  #ifndef ARM_MMU_EXTENDED
 @@ -3807,7 +3841,6 @@ pmap_kremove(vaddr_t va, vsize_t len)
  #ifdef UVMHIST
  	u_int total_mappings = 0;
  #endif
 -
  	PMAPCOUNT(kenter_unmappings);

  	UVMHIST_FUNC(__func__); UVMHIST_CALLED(maphist);
 @@ -3815,15 +3848,15 @@ pmap_kremove(vaddr_t va, vsize_t len)
  	UVMHIST_LOG(maphist, " (va=%#jx, len=%#jx)", va, len, 0, 0);

  	const vaddr_t eva = va + len;
 +	pmap_t kpm = pmap_kernel();

 -	pmap_acquire_pmap_lock(pmap_kernel());
 +	pmap_acquire_pmap_lock(kpm);

  	while (va < eva) {
  		vaddr_t next_bucket = L2_NEXT_BUCKET_VA(va);
  		if (next_bucket > eva)
  			next_bucket = eva;

 -		pmap_t kpm = pmap_kernel();
  		struct l2_bucket * const l2b = pmap_get_l2_bucket(kpm, va);
  		KDASSERT(l2b != NULL);

 @@ -3879,7 +3912,7 @@ pmap_kremove(vaddr_t va, vsize_t len)
  		total_mappings += mappings;
  #endif
  	}
 -	pmap_release_pmap_lock(pmap_kernel());
 +	pmap_release_pmap_lock(kpm);
  	cpu_cpwait();
  	UVMHIST_LOG(maphist, "  <--- done (%ju mappings removed)",
  	    total_mappings, 0, 0, 0);
 @@ -5904,7 +5937,7 @@ pmap_growkernel(vaddr_t maxkvaddr)
  	 * whoops!   we need to add kernel PTPs
  	 */

 -	s = splhigh();	/* to be safe */
 +	s = splvm();	/* to be safe */
  	mutex_enter(kpm->pm_lock);

  	/* Map 1MB at a time */
 @@ -6147,15 +6180,8 @@ pmap_bootstrap(vaddr_t vstart, vaddr_t v
  #endif

  	VPRINTF("locks ");
 -#if defined(PMAP_CACHE_VIPT) && !defined(ARM_MMU_EXTENDED)
 -	if (arm_cache_prefer_mask != 0) {
 -		mutex_init(&pmap_lock, MUTEX_DEFAULT, IPL_VM);
 -	} else {
 -#endif
 -		mutex_init(&pmap_lock, MUTEX_DEFAULT, IPL_NONE);
 -#if defined(PMAP_CACHE_VIPT) && !defined(ARM_MMU_EXTENDED)
 -	}
 -#endif
 +	mutex_init(&pmap_pg_lock, MUTEX_DEFAULT, IPL_VM);
 +	mutex_init(&kpm_lock, MUTEX_DEFAULT, IPL_VM);
  	mutex_init(&pm->pm_obj_lock, MUTEX_DEFAULT, IPL_NONE);
  	uvm_obj_init(&pm->pm_obj, NULL, false, 1);
  	uvm_obj_setlock(&pm->pm_obj, &pm->pm_obj_lock);

 --cWoXeonUoKmBZSoM--

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.