[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: VOP_GETATTR: locking protocol change proposal
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.
Main Index |
Thread Index |