NetBSD Problem Report #46053

From hf@spg.tu-darmstadt.de  Sun Feb 19 12:53:30 2012
Return-Path: <hf@spg.tu-darmstadt.de>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id A528763CAE9
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 19 Feb 2012 12:53:30 +0000 (UTC)
Message-Id: <201202191248.q1JCmuAr028502@Gurgler.nt.e-technik.tu-darmstadt.de>
Date: Sun, 19 Feb 2012 13:48:56 +0100 (CET)
From: Hauke Fath <hf@spg.tu-darmstadt.de>
Reply-To: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@gnats.NetBSD.org
Cc: Hauke Fath <hf@spg.tu-darmstadt.de>
Subject: Diagnostic assertion "oldsize != VSIZENOTSET || pgend > oldsize" failed in uvm/uvm_vnode.c
X-Send-Pr-Version: 3.95

>Number:         46053
>Category:       kern
>Synopsis:       Diagnostic assertion "oldsize != VSIZENOTSET || pgend > oldsize" failed in uvm/uvm_vnode.c
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Feb 19 12:55:02 +0000 2012
>Last-Modified:  Sat Aug 15 09:00:00 +0000 2015
>Originator:     Hauke Fath
>Release:        NetBSD 6.0_BETA
>Organization:
	Technische Universitaet Darmstadt

>Environment:


System: NetBSD 6.0_BETA 
Architecture: i386
Machine: i386
>Description:

	I dumped the partitions of a fileserver to re-organise the HW
	RAID layout. The restored system (major difference: The data
	partition was 'newfs -O2'ed with 64k/8k instead of the previous
	32k/4k) boots single-user, but during multi-user boot panics
	both with netbsd-5 and netbsd-6 kernels with

	(netbsd-5)

[...]
Starting mountd.
Starting nfsd.
Starting statd.
Starting lockd.
panic: kernel diagnostic assertion "oldsize != VSIZENOTSET || pgend > oldsize" failed: file "/public/netbsd-5/sys/uvm/uvm_vnode.c", line 353
Begin traceback...
uvm_fault(0xc0568d80, 0xfffff000, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c0381731 cs 8 eflags 10246 cr2 ffffffff ilevel 0
panic: trap
Faulted in mid-traceback; aborting...
dumping to dev 19,1 offset 8
dump amr0: bad status (not active; 0x0416)
127 amr0: bad status (not active; 0x0416)
amr0: bad status (not active; 0x0412)
[...]
56 amr0: bad status (not active; 0x0416)
error 35


amr0: bad status (not active; 0x040)
rebooting...


[...]
Starting mountd.
Starting nfsd.
Starting statd.
Starting lockd.
Starting virecover.
Starting local daemons:.
Starting lpd.
Updating motd.
panic: kernel diagnostic assertion "oldsize != VSIZENOTSET || pgend > oldsize" failed: file "/public/netbsd-5/sys/uvm/uvm_vnode.c", line 353
Begin traceback...
WARNING: SPL NOT LOWERED ON SYSCALL EXIT
uvm_fault(0xc056ff40, 0xfffff000, 1) -> 0xe
WARNING: SPL NOT LOWERED ON TRAP EXIT
fatal page faultWARNING: SPL NOT LOWERED ON TRAP EXIT
 in supervisor mode
WARNING: SPL NOT LOWERED ON TRAP EXIT
trap type 6 code 0 eip c0381a61 cs 8 eflags 10246 cr2 ffffffff ilevel 0
WARNING: SPL NOT LOWERED ON TRAP EXIT
panic: WARNING: SPL NOT LOWERED ON TRAP EXIT
trapWARNING: SPL NOT LOWERED ON SYSCALL EXIT

WARNING: SPL NOT LOWERED ON TRAP EXIT
Faulted in mid-traceback; aborting...WARNING: SPL NOT LOWERED ON TRAP EXIT

dumping to dev 19,1 offset 8
WARNING: SPL NOT LOWERED ON TRAP EXIT
dump WARNING: SPL NOT LOWERED ON TRAP EXIT
[...]
rebooting...


	(netbsd-6)

[...]
Starting mountd.
Starting nfsd.
Starting statd.
panic: keStarting lockd.rnel diagnostic assertion "oldsize != VSIZENOTSET || pgend > oldsize" failed: file "/public/netbsd-6/sys/uvm/uvm_vnode.c", line 350 
cpu1: Begin traceback...
kern_assert(c0b6a714,c0b6a8c5,c0c1374c,c0c13670,15e,dd31588c,dd31581c,c0851268,dd3157f8,ffffffff) at netbsd:kern_assert+0x23
uvm_vnp_setsize(c7c9cb0c,fbf3f850,fb46fb2b,dd31588c,0,0,dd315890,c08b4e36,3f,c0cd7df8) at netbsd:uvm_vnp_setsize+0x1bf
ffs_vget(c4fc2000,2627a00,0,dd3158d0,0,0,dd3158fc,0,3f,c4c97000) at netbsd:ffs_vget+0x427
ufs_fhtovp(c4fc2000,dd315908,dd315aa0,7,c483b744,c,2627a00,23dcc3a0,c4fc2000,dd315aa0) at netbsd:ufs_fhtovp+0x31
ffs_fhtovp(c4fc2000,dd315ab8,dd315aa0,c7cb3d40,c0ccbdc0,c0ccbdc0,dd31596c,c7cb9f18,dd315aa0,0) at netbsd:ffs_fhtovp+0x6c
VFS_FHTOVP(c4fc2000,dd315ab8,dd315aa0,dd315978,dd31597c,0,dd3159cc,c08a6521,c0ccbdc0,100) at netbsd:VFS_FHTOVP+0x27
nfsrv_fhtovp(dd315aac,1,dd315aa0,c7c82300,c45ed000,c4ddde00,dd315a98,0,0,0) at netbsd:nfsrv_fhtovp+0x99
nfsrv_getattr(c7cb9f18,c45ed000,c7cb3d40,dd315b68,ffffffff,c7bff2a8,dd315c8c,c7cb3d40,c7cb5e24,2) at netbsd:nfsrv_getattr+0x18c
nfssvc_nfsd(dd315bf0,b87ff928,c7cb3d40,0,0,0,0,c07b0571,0,0) at netbsd:nfssvc_nfsd+0x19f
sys_nfssvc(c7cb3d40,dd315cf4,dd315d1c,0,c7c79a80,0,0,c7cb2800,cb50e000,c7cb3d40) at netbsd:sys_nfssvc+0x237

syscall(dd315d48,b3,ab,1f,1f,0,b8600000,b87ff9ac,b87ff928,4) at netbsd:syscall+0xad
cpu1: End traceback...

dumping to dev 19,1 offset 8
dump amr0: bad status (not active; 0x0416)
amr0: bad status (not active; 0x0412)
amr0: bad status (not active; 0x0416)
amr0: bad status (not active; 0x0416)
amr0: bad status (not active; 0x0412)
135 earrmror0 :3 b5
ad
 s
tatus (not active; 0x040)
rebooting...


	The complaints from the amr(4) RAID controller driver may or
	may not be from a confused kernel. The machine worked fine
	before with uptimes 150+ d.

	Forcing a full fsck on all the volumes did not make a
	difference.

	Disabling the nfs server and its helper daemons appears 
	to avoid the panic, but leaves the NFS server useless.

	I am aware of PR 43287, however the hardware and kernel
	versions are reasonably different so I didn't want to
	hijack 43287.


>How-To-Repeat:

	See above; the panic is repeatable on my machine, although I
	do not understand what change made it behave that way.

>Fix:
	No idea.

>Release-Note:

>Audit-Trail:
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org
Subject: Re: kern/46053: Diagnostic assertion failed in uvm/uvm_vnode.c
Date: Sun, 19 Feb 2012 14:26:25 +0100

 After activating the nfs supporting cast minus nfsd in rc.conf, the machine
 boots fine.

 Manually starting nfsd then leads to

 [root@venediger] ~ # /etc/rc.d/nfsd onestart
 Starting nfsd.
 [root@venediger] ~ # panic: kernel diagnostic assertion "oldsize !=
 VSIZENOTSET || pgend > oldsize" failed: file
 "/public/netbsd-5/sys/uvm/uvm_vnode.c", line 353
 Begin traceback...
 uvm_fault(0xc056ff40, 0xfffff000, 1) -> 0xe
 fatal page fault in supervisor mode
 trap type 6 code 0 eip c0381a61 cs 8 eflags 10246 cr2 ffffffff ilevel 0
 panic: trap
 Faulted in mid-traceback; aborting...
 dumping to dev 19,1 offset 8
 [...]

 -- 

From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org
Subject: Re: kern/46053: Diagnostic assertion failed in uvm/uvm_vnode.c
Date: Sun, 19 Feb 2012 15:20:11 +0100

 At 13:35 Uhr +0000 19.02.2012, Hauke Fath wrote:
 > After activating the nfs supporting cast minus nfsd in rc.conf, the machine
 > boots fine.

 The same setting with a non-debug netbsd-5 kernel leads to


 [root@venediger] ~ # /etc/rc.d/nfsd onestart
 Starting nfsd.
 [root@venediger] ~ # ifree: dev = 0x1307, ino = 52985292, fs = /u
 ifree: dev = 0x1307, ino = 53172769, fs = /u
 panic: ifree: freeing free inode
 Begin traceback...
 uvm_fault(0xf09d1ef4, 0, 1) -> 0xe
 fatal page fault in supervisor mode
 trap type 6 code 0 eip c0346ef1 cs 8 eflags 10246 cr2 0 ilevel 0
 panic: trap
 Faulted in mid-traceback; aborting...
 dumping to dev 19,1 offset 8
 dump amr0: bad status (not active; 0x040)


 and a GENERIC netbsd-6 kernel gives me


 [root@venediger] ~ # /etc/rc.d/nfsd onestart
 Starting nfsd.
 [root@venediger] ~ # panic: Feb 19 14:47:42 kernel diagnostic assertion
 "oldsize != VSIiZfrEeNOe:TS EdeT v| =|  0pxg1en3d07 >,  oilndo s=iz e4"14
 6f0ai62l0e,d : ffsi =l e
 public/netbsd-6/sys/uvm/uvm_vnode.c", line 350
 cpu1: Begin traceback...
 kern_assert(c0b6a714,c0b6a8c5,c0c1374c,c0c13670,15e,dd49682c,dd4967bc,c0851268,dd496798,ffffffff)
 at netbsd:kern_assert+0x23
 uvm_vnp_setsize(c7d65638,b4cadf9e,d0483833,dd49682c,0,0,dd496830,c054186a,6,dd496860)
 at netbsd:uvm_vnp_setsize+0x1bf
 ffs_vget(c4a25000,28a907f,0,dd496870,4e45382,c4c99600,c7d1fc74,0,0,5dc) at
 netbsd:ffs_vget+0x427
 ufs_fhtovp(c4a25000,dd4968a8,dd496a90,7,c49d4744,c,28a907f,174cdf23,c4a25000,dd496a90)
 at netbsd:ufs_fhtovp+0x31
 ffs_fhtovp(c4a25000,dd496ab8,dd496a90,c4e18000,c7d1fc40,4000,dd49693c,c7dedf18,dd496a90,0)
 at netbsd:ffs_fhtovp+0x6c
 VFS_FHTOVP(c4a25000,dd496ab8,dd496a90,dd496918,dd49691c,1,dd496974,c7d1fc40,c7d1e018,100)
 at netbsd:VFS_FHTOVP+0x27
 nfsrv_fhtovp(dd496aac,1,dd496a90,c7d4bf00,c45ed000,c4760f00,dd496a9c,0,0,ffffffff)
 at netbsd:nfsrv_fhtovp+0x99
 nfsrv_read(c7dedf18,c45ed000,c7de7020,dd496b68,ffffffff,c7d7e8b8,dd496c8c,c7de7020,c7d63224,2)
 at netbsd:nfsrv_read+0x23f
 nfssvc_nfsd(dd496bf0,b9fffa28,c7de7020,0,0,0,0,c07b0571,0,0) at
 netbsd:nfssvc_nfsd+0x19f
 sys_nfssvc(c7de7020,dd496cf4,dd496d1c,0,dd1bcdc0,c7cade98,0,c7deac00,c7deac00,c7de7020)
 at netbsd:sys_nfssvc+0x237
 venediger
 /netbssyscall(dd496d48,b3,ab,1f,1f,0,b9800000,b9fffaac,b9fffa28,4) at
 netbsd:syscall+0xad
 cpu1: End traceback...

 dumping to dev 19,1 offset 8
 dump d: panic: k
 amr0: bad status (not active; 0x0416)
 amr0: bad status (not active; 0x0416)
 142 amr0: bad status (not active; 0x0412)
 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123
 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104
 103 102 101 100

 rebooting...

 -- 

From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org
Subject: Re: kern/46053: Diagnostic assertion failed in uvm/uvm_vnode.c
Date: Thu, 23 Feb 2012 12:13:47 +0100

 Update:

 I had to bring up the machine ASAP (still struggling with it, though), so I
 re-installed. After newfs'ing the data partition with 32K/4K blocksize, I
 haven't seen the panic again.

 OTOH, it looks like I have been there before: The panic I reported after a
 previous hw upgrade in kern/44651 looks suspiciously similar. I remember
 when I tried a non-{DEBUG,DIAGNOSTIC} kernel this time, I also got a
 "freeing free inode" panic.

 	hauke

 -- 
      The ASCII Ribbon Campaign                    Hauke Fath
 ()     No HTML/RTF in email            Institut für Nachrichtentechnik
 /\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf +49-6151-16-3281

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/46053: Diagnostic assertion failed in uvm/uvm_vnode.c
Date: Sun, 18 Mar 2012 16:52:20 +0000

 On Sun, Feb 19, 2012 at 03:05:04PM +0000, Hauke Fath wrote:
  >  [root@venediger] ~ # panic: Feb 19 14:47:42 kernel diagnostic assertion
  >  "oldsize != VSIiZfrEeNOe:TS EdeT v| =|  0pxg1en3d07 >,  oilndo s=iz e4"14
  >  6f0ai62l0e,d : ffsi =l e
  >  public/netbsd-6/sys/uvm/uvm_vnode.c", line 350

 For the record, that's the beginning of the "freeing free inode"
 message overlaid with the "oldsize != VSIZENOTSET || pgend > oldsize"
 UVM assertion.

 "freeing free inode" is almost always caused by fs corruption. If
 you're getting repeated fs corruption, fscking once in a while before
 it becomes lethal may both keep the system running and help to track
 down what's wrong.

 The UVM assertion looks strange to me:

    oldsize = vp->v_writesize;
    KASSERT(oldsize != VSIZENOTSET || pgend > oldsize);

    if (oldsize > pgend) {

 so, we assert that either oldsize is not VSIZENOTSET, or if it *is*
 VSIZENOTSET, that pgend > VSIZENOTSET. Since VSIZENOTSET is
 (voff_t)-1, and voff_t is signed, it seems like this can only fail if
 the new size passed in is negative... and less than -4096, since pgend
 is round_page(newsize) and round_page(-1) will produce 0. That seems
 very weird.

 It's also a crazy thing to be asserting, and a crazy way to assert
 that newsize isn't negative, so I'm thinking it's probably just wrong
 and something else must have been intended. But maybe I'm missing
 something...

 -- 
 David A. Holland
 dholland@netbsd.org

From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org
Subject: Re: kern/46053: Diagnostic assertion failed in uvm/uvm_vnode.c
Date: Fri, 23 Mar 2012 10:20:04 +0100

 FTR, I got this panic from a netbsd-6 kernel two days ago:

 [...]
 [-- MARK -- Thu Mar 22 12:00:00 2012]
 uvm_fault(0xc51acafc, 0, 1) -> 0xe
 fatal page fault in supervisor mode
 trap type 6 code 0 eip c04cf324 cs 8 eflags 210246 cr2 84 ilevel 0
 panic: trap
 cpu3: Begin traceback...
 panic(c067ef24,e8818844,e8818844,c04cf324,8,210246,84,0,c85ed480,84) at
 netbsd:panic+0x18
 trap() at netbsd:trap+0xcd2
 --- trap (number 6) ---
 ufs_fhtovp(c51ce000,e88188d8,e8818a80,c02d2e37,c4f6ae7e,c,2627a00,23dcc3a0,c5881944,c5442d3c)
 at netbsd:ufs_fhtovp+0x44
 ffs_fhtovp(c51ce000,e8818a98,e8818a80,0,c4f93d80,c4f773d0,e881896c,cbd20f24,e8818a80,0)
 at netbsd:ffs_fhtovp+0x75
 VFS_FHTOVP(c51ce000,e8818a98,e8818a80,e8818958,e881895c,0,e88189bc,c045cf61,6,100)
 at netbsd:VFS_FHTOVP+0x27
 nfsrv_fhtovp(e8818a8c,1,e8818a80,c857acc0,c5df7b80,d7183500,e8818a78,0,0,30)
 at netbsd:nfsrv_fhtovp+0x98
 nfsrv3_access(cbd20f24,c5df7b80,c811b540,e8818b68,0,0,0,1,22,1) at
 netbsd:nfsrv3_access+0x1b5
 nfssvc_nfsd(e8818bf0,b63ffa28,c811b540,0,0,0,0,c542612c,c544f540,567ec) at
 netbsd:nfssvc_nfsd+0x197
 sys_nfssvc(c811b540,e8818cf4,e8818d1c,c04adffe,c51acafc,b63fe000,2,0,c5423800,c811b540)
 at netbsd:sys_nfssvc+0x23b
 syscall(e8818d48,80400b3,b62000ab,bf7f001f,bb7b001f,b63ffaa8,b6200000,b63ffab4,b63ffa28,b6200010)
 at netbsd:syscall+0xad
 cpu3: End traceback...

 dumping to dev 19,1 offset 8
 dump 665 664 error 35


 It is the first panic of this kind since returning to a 32k ffs for the 1.6
 TB data partition.

 -- 

From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
        David Holland <dholland-bugs@NetBSD.org>
Subject: Re: kern/46053: Diagnostic assertion failed in uvm/uvm_vnode.c
Date: Fri, 23 Mar 2012 10:23:41 +0100

 At 16:55 Uhr +0000 18.03.2012, David Holland wrote:
 > If
 > you're getting repeated fs corruption, fscking once in a while before
 > it becomes lethal may both keep the system running and help to track
 > down what's wrong.

 The file system in question was freshly restored from a dump. While that
 does not make fs corruption impossible, the fact that reducing blocksize of
 the fs in question from 64K to 32K made the panic go away (until recently,
 see my other mail) would speak against it.

 	hauke

 -- 

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
        Hauke Fath <hf@spg.tu-darmstadt.de>
Subject: Re: kern/46053: Diagnostic assertion failed in uvm/uvm_vnode.c
Date: Fri, 23 Mar 2012 14:07:21 +0100

 On Fri, Mar 23, 2012 at 09:30:07AM +0000, Hauke Fath wrote:
 > The following reply was made to PR kern/46053; it has been noted by GNATS.
 > 
 > From: Hauke Fath <hf@spg.tu-darmstadt.de>
 > To: gnats-bugs@NetBSD.org
 > Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org
 > Subject: Re: kern/46053: Diagnostic assertion failed in uvm/uvm_vnode.c
 > Date: Fri, 23 Mar 2012 10:20:04 +0100
 > 
 >  FTR, I got this panic from a netbsd-6 kernel two days ago:
 >  
 >  [...]
 >  [-- MARK -- Thu Mar 22 12:00:00 2012]
 >  uvm_fault(0xc51acafc, 0, 1) -> 0xe
 >  fatal page fault in supervisor mode
 >  trap type 6 code 0 eip c04cf324 cs 8 eflags 210246 cr2 84 ilevel 0
 >  panic: trap
 >  cpu3: Begin traceback...
 >  panic(c067ef24,e8818844,e8818844,c04cf324,8,210246,84,0,c85ed480,84) at
 >  netbsd:panic+0x18
 >  trap() at netbsd:trap+0xcd2
 >  --- trap (number 6) ---
 >  ufs_fhtovp(c51ce000,e88188d8,e8818a80,c02d2e37,c4f6ae7e,c,2627a00,23dcc3a0,c5881944,c5442d3c)
 >  at netbsd:ufs_fhtovp+0x44

 This is PR kern/46221, which is being looked at.

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

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46053: Diagnostic assertion failed in uvm/uvm_vnode.c
Date: Fri, 23 Mar 2012 14:39:46 +0000

 On Fri, Mar 23, 2012 at 10:00:07AM +0000, Hauke Fath wrote:
  >  At 16:55 Uhr +0000 18.03.2012, David Holland wrote:
  >  > If
  >  > you're getting repeated fs corruption, fscking once in a while before
  >  > it becomes lethal may both keep the system running and help to track
  >  > down what's wrong.
  >  
  >  The file system in question was freshly restored from a dump. While that
  >  does not make fs corruption impossible, the fact that reducing blocksize of
  >  the fs in question from 64K to 32K made the panic go away (until recently,
  >  see my other mail) would speak against it.

 Yes.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Shawn Novak <kernel86@gmail.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46053: Diagnostic assertion failed in uvm/uvm_vnode.c
Date: Tue, 3 Jul 2012 04:33:39 -0500

 I've been experiencing this bug as well.  In my case, like bug 43287,
 it appears to be happening after the nightly cron jobs.

 I'm running the generic 6.0_BETA2 release kernel in VMware ESXi 5.0.
 With the exception of the system disk most of the storage in this
 system is being provided as Raw Disk Mappings of iSCSI luns from esx
 and is being managed with NetBSD's lvm.  The volumes are all formatted
 with FFSv2 and mounted with the log option.

 The latest core dump and dmesg output can be found below:
 ftp://ftp.muleslow.net/netbsd/cores/dmesg.out
 ftp://ftp.muleslow.net/netbsd/cores/netbsd.6.core.gz

 The relevant excerpts from dmesg:

 panic: kernel diagnostic assertion "oldsize != VSIZENOTSET || pgend >
 oldsize" failed: file "/usr/src/sys/uvm/uvm_vnode.c", line 350
 cpu0: Begin traceback...
 kern_assert(c0b76654,c0b76820,c0c1f0d0,c0c1efa6,15e,cdcd687c,cdcd680c,c0859988,cdcd67e8,ffffffff)
 at netbsd:kern_assert+0x23
 uvm_vnp_setsize(c23e4f2c,41b97ae4,e49b946e,cdcd687c,0,0,cdcd6880,0,0,4)
 at netbsd:uvm_vnp_setsize+0x1bf
 ffs_vget(c1ccc000,49b06e,0,cdcd695c,cdcd6960,0,c0c20ade,c298c400,c298c370,200)
 at netbsd:ffs_vget+0x427
 ufs_lookup(cdcd69b4,c1956420,cdcd69cc,c08fc0b1,cdcd69bc,c22e69b0,0,c1956420,20000,20002)
 at netbsd:ufs_lookup+0x854
 VOP_LOOKUP(c1956420,cdcd6a20,cdcd6bc4,2,c1405160,c1956420,cdcd6a3c,c08dd60d,c1956420,2)
 at netbsd:VOP_LOOKUP+0x33
 lookup_once(cdcd6aec,cdcd6ae8,4,c08de7b6,c194d8cc,cdcd6b98,cdcd6aac,c198d630,cdcd6acc,c0b662b4)
 at netbsd:lookup_once+0x19f
 namei_tryemulroot(0,1,0,c1875cc0,c1875cc0,c0ca0dcc,cdcd6cf4,c08cd500,bb915074,c201cc00)
 at netbsd:namei_tryemulroot+0x21e
 namei(cdcd6ba0,cdcd6be0,cdcd6bbc,c08fbee5,cdcd6bac,0,cdcd6c8c,0,5,c0b66200)
 at netbsd:namei+0x29
 do_sys_stat(bb915074,0,cdcd6c08,200,0,a902,0,81a4,49b06d,0) at
 netbsd:do_sys_stat+0x47
 sys___lstat50(c22e67e0,cdcd6cf4,cdcd6d1c,0,c0694acc,c1fbbcc0,c22e67e0,c186a960,c0694acc,c186a80c)
 at netbsd:sys___lstat50+0x2a
 syscall(cdcd6d48,bb9000b3,ab,bfbf001f,bb90001f,bb915020,bb915088,bfbfeb58,bbbb1598,bb915020)
 at netbsd:syscall+0xad
 cpu0: End traceback...

 --Shawn Novak

From: Michael van Elst <mlelstv@serpens.de>
To: gnats-bugs@gnats.netbsd.org
Cc: 
Subject: Re: kern/46053: Diagnostic assertion "oldsize != VSIZENOTSET ||
 pgend > oldsize" failed
Date: Sat, 15 Aug 2015 10:54:56 +0200

 The UVM assertion is strange.

 Here is something more sensible:

 Index: sys/uvm/uvm_vnode.c
 ===================================================================
 RCS file: /cvsroot/src/sys/uvm/uvm_vnode.c,v
 retrieving revision 1.99
 diff -u -r1.99 uvm_vnode.c
 --- sys/uvm/uvm_vnode.c	30 Jul 2012 23:56:48 -0000	1.99
 +++ sys/uvm/uvm_vnode.c	15 Aug 2015 08:32:59 -0000
 @@ -346,15 +346,19 @@
  	 * toss some pages...
  	 */

 -	KASSERT(newsize != VSIZENOTSET);
 +	KASSERT(newsize != VSIZENOTSET && newsize >= 0);
  	KASSERT(vp->v_size <= vp->v_writesize);
  	KASSERT(vp->v_size == vp->v_writesize ||
  	    newsize == vp->v_writesize || newsize <= vp->v_size);

  	oldsize = vp->v_writesize;
 -	KASSERT(oldsize != VSIZENOTSET || pgend > oldsize);

 -	if (oldsize > pgend) {
 +	/*
 +	 * check wether size shrinks
 +	 * if old size hasn't been set, there are no pages to drop
 +	 * if there was an integer overflow in pgend, then this is no shrink
 +	 */
 +	if (oldsize > pgend && oldsize != VSIZENOTSET && pgend >= 0) {
  		(void) uvn_put(uobj, pgend, 0, PGO_FREE | PGO_SYNCIO);
  		mutex_enter(uobj->vmobjlock);
  	}
 @@ -367,7 +371,7 @@
  {

  	mutex_enter(vp->v_interlock);
 -	KASSERT(newsize != VSIZENOTSET);
 +	KASSERT(newsize != VSIZENOTSET && newsize >= 0);
  	KASSERT(vp->v_size != VSIZENOTSET);
  	KASSERT(vp->v_writesize != VSIZENOTSET);
  	KASSERT(vp->v_size <= vp->v_writesize);


 However, this doesn't change why the assertion happened. newsize
 must have been negative (and less than -4096).

 FFS passes these values directly from the on-disk inode. So the
 filesystem could be damaged, or the data isn't read correctly from
 the disk, or something else is trashing memory.

 fsck_ffs treats the size as unsigned and will find negative inode
 sizes (unless its UFS2 and the superblock is damaged too, but
 then anything regular will be seen as an error).





 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.