Re: kern/56931: Panic in vfs_insmntque(): panic: TAILQ_* forw 0xffffec0928771d00 /usr/src/sys/kern/vfs_mount.c:487

[Leonardo Taccari <leot%NetBSD.org@localhost>]

The following reply was made to PR kern/56931; it has been noted by GNATS.

From: Leonardo Taccari <leot%NetBSD.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/56931: Panic in vfs_insmntque(): panic: TAILQ_* forw 0xffffec0928771d00 /usr/src/sys/kern/vfs_mount.c:487
Date: Sun, 17 Jul 2022 23:50:38 +0200

 leot%NetBSD.org@localhost writes:
 > [...]
 > >Description:
 > 	From NetBSD 9.99.98 of Jul 16 while building pkgsrc packages (it was
 > 	probably at the `make package' or `make install' phase of www/firefox91)
 > 	the system panic-ed as follows:
 >
 > 	panic: TAILQ_* forw 0xffffec0928771d00 /usr/src/sys/kern/vfs_mount.c:487
 > 	cpu0: Begin traceback...
 > 	vpanic() at netbsd:vpanic+0x18c
 > 	panic() at netbsd:panic+0x3c
 > 	vfs_insmntque() at netbsd:vfs_insmntque+0x2be
 > 	vcache_reclaim() at netbsd:vcache_reclaim+0x280
 > 	vrelel() at netbsd:vrelel+0x2e2
 > 	tmpfs_remove() at netbsd:tmpfs_remove+0x1bb
 > 	VOP_REMOVE() at netbsd:VOP_REMOVE+0x5b
 > 	do_sys_unlinkat() at netbsd:do_sys_unlinkat+0x2a1
 > 	syscall() at netbsd:syscall+0x19e
 >
 > 	If possible further information are needed I have also a coredump
 > 	available.
 > >How-To-Repeat:
 > 	Unfortunately, it is not clear to me yet to how to reproduce it
 > 	reliably. The machine built several pkgsrc packages overnight without
 > 	any problems. pkgsrc WRKOBJDIR is set to a tmpfs.
 > [...]
 
 I was able to reproduce that again when building www/webkit-gtk and at
 least in that case I think it was while doing a `make clean' (at least
 that was the last line I was able to read from an SSH session after it
 get stuck and dropped to ddb(4)), the bt seems the same:
 
  panic: TAILQ_* forw 0xffff98a871b71d00 /usr/src/sys/kern/vfs_mount.c:487
  cpu1: Begin traceback...
  vpanic() at netbsd:vpanic+0x18c
  panic() at netbsd:panic+0x3c
  vfs_insmntque() at netbsd:vfs_insmntque+0x2be
  vcache_reclaim() at netbsd:vcache_reclaim+0x280
  vrelel() at netbsd:vrelel+0x2e2
  tmpfs_remove() at netbsd:tmpfs_remove+0x1bb
  VOP_REMOVE() at netbsd:VOP_REMOVE+0x5b
  do_sys_unlinkat() at netbsd:do_sys_unlinkat+0x2a1
  syscall() at netbsd:syscall+0x19e
  --- syscall (number 10) ---
  netbsd:syscall+0x19e:
  cpu1: End traceback...
  fatal breakpoint trap in supervisor mode
  trap type 1 code 0 rip 0xffffffff80221a65 cs 0x8 rflags 0x202 cr2 0x7ddf9bcc5028 ilevel 0 rsp 0xffffaa0280374c40
  curlwp 0xffff98a97682e780 pid 19014.19014 lowest kstack 0xffffaa02803702c0
 
 Looking at `ps' from crash(8) it seems that in both cases rm(1) was
 running (from 1st panic that was originally attached in the Description
 of this PR):
 
  crash> ps
  PID    LID  S CPU     FLAGS       STRUCT LWP *               NAME WAIT
  3205 >3205  7   0     40000   ffffec0e8b868480                 rm
  19716 19716 3   1       180   ffffec0dc10d5580               make wait
  22344 22344 3   0       180   ffffec08d217c300                 sh wait
 
 ...and (2nd panic while probably cleaning www/webkit-gtk):
 
  crash> ps
  PID    LID  S CPU     FLAGS       STRUCT LWP *               NAME WAIT
  19014>19014 7   1         0   ffff98a97682e780                 rm
  15655 15655 3   0       180   ffff98a81cf834c0               make wait
  2133  2133  3   1       180   ffff98aa95fb5600                 sh wait