Re: kern/46053: Diagnostic assertion "oldsize != VSIZENOTSET || pgend > oldsize" failed

[Michael van Elst <mlelstv%serpens.de@localhost>]

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

From: Michael van Elst <mlelstv%serpens.de@localhost>
To: gnats-bugs%gnats.netbsd.org@localhost
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@localhost
                                 "A potential Snark may lurk in every tree."