port-evbmips/50059: evbmips-mips64el panic writing to ext2fs file system

[jdbaker%mylinuxisp.com@localhost]

>Number:         50059
>Category:       port-evbmips
>Synopsis:       evbmips-mips64el panic writing to ext2fs file system
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-evbmips-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 17 20:45:00 +0000 2015
>Originator:     John D. Baker
>Release:        NetBSD/ebvmips-7.99.20 (evbmips-mips64el, LOONGSON)
>Organization:
>Environment:
NetBSD chalk.technoskunk.fur 7.99.20 NetBSD 7.99.20 (YEELOONG) #10: Tue Jul 14 16:30:58 CDT 2015  sysop%verthandi.technoskunk.fur@localhost:/d0/build/current/obj/mips64el/sys/arch/evbmips/compile/YEELOONG evbmips

>Description:
Beginning around 7.99.15, writing to an ext2fs file system on a Lemote
Yeeloong (evbmips-mips64el, LOONGSON) produced system hangs or panics
with the following message:

panic: kernel diagnostic assertion "vp->v_type == VREG" failed: file
"/x/current/src/sys/ufs/ext2fs/ext2fs_readwrite.c", line 286
kernel: breakpoint trap
Stopped in pid 16366.1 (cvs) at ffffffff8023d88c:       li      at,0x3
db> bt
980000008110f860: 0+ffffffff8023d88c (63061,0,0,ffffffff80668ef0) ra 0 sz 0
User-level: pid 16366.1
db>


While the above message was captured during a 'cvs update' operation,
it is most readily triggered by extracting a tar archive to a target
directory on an ext2fs file system.

My system has the following local media:

/dev/sd0a on / type ffs (log, noatime, local)
/dev/sd0e on /var type ffs (log, noatime, nosuid, local)
/dev/wd0m on /d0 type ext2fs (nodev, nosuid, local)
/dev/wd0i on /tmp type ext2fs (nodev, nosuid, local)

"sd0" is an SD card in the Yeeloong's SD card slot
"wd0" is the Yeeloong's internal 160GB 2.5-inch SATA disk from
which I share the swap partition, "/tmp" and "/d0" between gnuSense
3.x (Parkes), OpenBSD 5.x, and NetBSD-current.

Prior to 7.99.15 (or so, whenever the last time evbmips-mips64el was
buildable), there was never any problem with writing to ext2fs.
>How-To-Repeat:
Mount an ext2fs file system on which you can write, such as "/tmp" in
the above example.

Extract a tar archive to "/tmp", e.g.,

  $ tar xzf etc.tgz -C /tmp

Or for more complete example, use 'etcupdate' with and ext2fs
file system mounted as "/tmp":

  $ cd /path/to/sets
  $ su
  # sh /usr/sbin/etcupdate -alv -s etc.tgz -s xetc.tgz

Observe hang or panic.  (If "ddb.onpanic=1" it will likely hang without
displaying any diagnostic.  If "ddb.onpanic=0" it may silently write
a core image to swap and reboot.  Typically, 'savecore' is unable to
recover the core image.)

>Fix: