[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/46235: beating on ftruncate kills the system
The following reply was made to PR kern/46235; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
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
Main Index |
Thread Index |