panic: assertion: p->p_lock == 0 in kern_wait

[YONETANI Tomokazu <y0n3t4n1@xxxxxxxxx>]

Hi.
Apparently a few hours of pbulk test can trigger this panic (this is
on x86_64 and the kernel is built from source as of 5347900e6).
As opposed to what KKASSERT claims, p->p_lock doesn't hold the non-zero
value in the frame 5:

  #4  0xffffffff802ad259 in panic (fmt=0xffffffff804f212a "assertion: %s in %s")
      at /usr/src/sys/kern/kern_shutdown.c:799
  #5  0xffffffff802989a1 in kern_wait (pid=<value optimized out>,
      status=0xffffffe05e997a74, options=1528637672, rusage=0x0,
      res=0xffffffe05e997b58) at /usr/src/sys/kern/kern_exit.c:901
  #6  0xffffffff80298c4e in sys_wait4 (uap=0xffffffe05e997b58)
      at /usr/src/sys/kern/kern_exit.c:754
  #7  0xffffffff804b580c in syscall2 (frame=0xffffffe05e997c08)
      at /usr/src/sys/platform/pc64/x86_64/trap.c:1182
  #8  0xffffffff804ae53f in Xfast_syscall ()
      at /usr/src/sys/platform/pc64/x86_64/exception.S:318
  #9  0x000000000000002b in ?? ()
  Backtrace stopped: previous frame inner to this frame (corrupt stack?)
  (kgdb) fr 5
  #5  0xffffffff802989a1 in kern_wait (pid=<value optimized out>,
      status=0xffffffe05e997a74, options=1528637672, rusage=0x0,
      res=0xffffffe05e997b58) at /usr/src/sys/kern/kern_exit.c:901
  901                             KKASSERT(p->p_lock == 0);
  (kgdb) p p->p_lock
  $1 = 0

I'm not sure if this is a problem in kgdb or a result of optimization,
or it's an MP race.