NetBSD Problem Report #50059

From www@NetBSD.org  Fri Jul 17 20:42:34 2015
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 5AF91A5858
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 17 Jul 2015 20:42:34 +0000 (UTC)
Message-Id: <20150717204232.F03FFA6551@mollari.NetBSD.org>
Date: Fri, 17 Jul 2015 20:42:32 +0000 (UTC)
From: jdbaker@mylinuxisp.com
Reply-To: jdbaker@mylinuxisp.com
To: gnats-bugs@NetBSD.org
Subject: evbmips-mips64el panic writing to ext2fs file system
X-Send-Pr-Version: www-1.0

>Number:         50059
>Category:       port-evbmips
>Synopsis:       evbmips-mips64el panic writing to ext2fs file system
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    riastradh
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 17 20:45:00 +0000 2015
>Closed-Date:    Fri Jan 22 15:05:27 +0000 2016
>Last-Modified:  Fri Jan 22 15:05:27 +0000 2016
>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:/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:

>Release-Note:

>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-evbmips/50059: evbmips-mips64el panic writing to ext2fs
 file system
Date: Sat, 18 Jul 2015 19:08:31 +0000

 On Fri, Jul 17, 2015 at 08:45:00PM +0000, jdbaker@mylinuxisp.com wrote:
  > 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.

 some things that would be useful for someone to check:

 (1) does this happen on other ports? and if not,
 (2) does this happen using compat_netbsd32 on other ports?

 It is far from impossible that someone simply broke ext2fs :-/

 -- 
 David A. Holland
 dholland@netbsd.org

From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-evbmips/50059: evbmips-mips64el panic writing to ext2fs
 file system
Date: Mon, 4 Jan 2016 12:40:50 -0600 (CST)

 See also:  kern/50607: ext2 repeatable kernel panic when creating files

 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/50059 CVS commit: src/sys/ufs/ext2fs
Date: Tue, 12 Jan 2016 21:29:29 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Tue Jan 12 21:29:29 UTC 2016

 Modified Files:
 	src/sys/ufs/ext2fs: ext2fs_lookup.c

 Log Message:
 Use buffer cache, not page cache, to expand directories in ext2fs.

 Candidate fix for PR kern/50607, PR port-evbmips/50059.

 Formerly VOP_WRITE-->ext2fs_write would automatically dispatch to
 this code path for writes to directories, but I broke that in
 ext2fs_lookup.c rev. 1.78 when disentangling page-cached and
 buffer-cached writes.

 This was not a problem in ufs, and I didn't notice it in ext2fs,
 because ufs consistently used buffercache(9) directly instead of
 using VOP_WRITE sometimes as ext2fs did.


 To generate a diff of this commit:
 cvs rdiff -u -r1.78 -r1.79 src/sys/ufs/ext2fs/ext2fs_lookup.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: PR/50059 CVS commit: src/sys/ufs/ext2fs
Date: Mon, 18 Jan 2016 23:07:54 -0600 (CST)

 On Tue, 12 Jan 2016, Taylor R Campbell wrote:

 >  Modified Files:
 >  	src/sys/ufs/ext2fs: ext2fs_lookup.c
 >  
 >  Log Message:
 >  Use buffer cache, not page cache, to expand directories in ext2fs.
 >  
 >  Candidate fix for PR kern/50607, PR port-evbmips/50059.

 This seems to fix the problem I was seeing.

 Thanks.

 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

Responsible-Changed-From-To: port-evbmips-maintainer->riastradh
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Fri, 22 Jan 2016 15:05:27 +0000
Responsible-Changed-Why:
mine


State-Changed-From-To: open->closed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 22 Jan 2016 15:05:27 +0000
State-Changed-Why:
Submitter reports fixed -- thanks!


>Unformatted:

Home	PR Database Search