Re: [NFS] [PATCH] mmap corruption
Steve Dickson (SteveD@RedHat.com)
Mon, 7 Apr 2003 10:00:52 -0400
On Sun, Apr 06, 2003 at 02:30:09PM +0200, Trond Myklebust wrote:
> >>>>> " " == Steve Dickson <SteveD@RedHat.com> writes:
> > /*
> > * Every time either npages or ncommit had a value and the file
> > size is
> > * immediately changed (with in a microsecond or two) by another
> > * truncation, followed by a mmap read, the file would be
> > corrupted.
> > */
> > if (NFS_I(inode)->npages || NFS_I(inode)->ncommit ||
> > NFS_I(inode)->ndirty) {
> > printk("nfs_notify_change: fid %Ld npages %d ncommit
> > %d ndirty %d\n", NFS_FILEID(inode),
> > NFS_I(inode)->npages, ncommit, NFS_I(inode)->ndirty);
> > }
> > }
>
> My point is that nfs_wb_all() is supposed to ensure that
> NFS_I(inode)->ncommit, and/or NFS_I(inode)->ndirty are both
> zero. i.e. you can have pending reads (in which case
> NFS_I(inode)->npages != 0), but *no* pending writes.
>
> Was this the case?
OK, I understand your point. And Yes, ndirty and ncommit
always seem to be zero when nfs_wb_all() returns. Only
when npages != 0 is when I get the corruption.
I didn't realize that npages != 0 meant there are only pending
reads *not* pending writes... Thanks for that clarification....
SteveD.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/