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:
(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.