Re: VOP_GETATTR: locking protocol change proposal

[Emmanuel Dreyfus <manu%netbsd.org@localhost>]

On Sun, Nov 20, 2011 at 09:40:35PM +0000, David Holland wrote:
> Also, retrieving data protected by a particular lock without holding
> it is inherently wrong; if we're going to move the file length out
> from under the main vnode lock we'd better do it explicitly.

Yes, this is begging for troubles.

FWIW I spent weeks tracking down a file corruption bug on growing giles
in PUFFS because VOP_GETATTR operates on an unlocked vnode. If the 
VOP_GETATTR request follows a not yet completed VOP_FSYNC (as done by 
ioflush thread), I got toasted: VOP_FSYNC causes PUFFS to send a SETATTR
to the filesystem, and on completion VOP_GETATTR gets from the filesystem
a file size smaller thant what VOP_FSYNC just set. This cause the file
to be truncated by the kernel, and data written between VOP_FSYNC
and VOP_GETATTR to be discarded and replaced by a chunk of zeroed bytes.

I had to add a lock on file size modification in PUFFS to fix the problem.

-- 
Emmanuel Dreyfus
manu%netbsd.org@localhost