Re: kern/46235: beating on ftruncate kills the system

[David Holland <dholland-bugs%netbsd.org@localhost>]

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

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/46235: beating on ftruncate kills the system
Date: Thu, 22 Mar 2012 17:17:08 +0000

 On Thu, Mar 22, 2012 at 12:40:00AM +0000, dholland%netbsd.org@localhost wrote:
  > The thing I was attempting to tickle is the lock release/reacquire
  > that's at line 354 of uvm_vnode.c in uvm_vnp_setsize(). ISTM that the
  > window that creates (though small) is dangerous. I'm not sure if I've
  > managed to hit it yet though.
 
 I don't know if the crashes described in the original PR are connected
 to this particular issue or have deeper causes, but if you run trunq
 on msdosfs it dies almost instantly with:
 
 panic: kernel diagnostic assertion "vp->v_size <= newsize" failed: file 
"/disk/disk1/home/dholland/netbsd/quotafix/src/sys/uvm/uvm_vnode.c", line 369 
 
 which seems very likely to be a result of hitting that window. 
 
  > If the thing in uvm_vnode.c turns out to be the problem, fixing the
  > VOP_PUTPAGES interface to not release locks it didn't take (why is it
  > doing that?) would take care of it, but would probably be kind of
  > invasive for the -6 branch.
 
 This will not work. It seems that genfs_putpages cycles in and out of
 that lock many, many times. This seems unhealthy in itself, perhaps,
 but in any event it means no such quick fix is possible.
 
 I have no idea what would happen if the size assignment after that
 window were moved to before it, to make it atomic, but I expect
 nothing good as then genfs_putpages will be working past EOF. Probably
 the size model needs to be extended so it's possible to assign the
 size before calling uvn_put(), but I don't know what this entails.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost