On Tue, 2006-10-03 at 16:13 -0700, Jeremy Allison wrote:
> On Tue, Oct 03, 2006 at 03:45:49PM -0500, Steve French wrote:
> > Dave Kleikamp wrote:
> > >>Someone had reported a problem with a writepages call coming in on with
> > >>no open files (so presumably the file was closed, with dirty pages not
> > >>written).
> > >>
> > >
> > >This is normal behavior for most file systems. I thought cifs protected
> > >this by flushing dirty data in cifs_close. I don't think any data
> > >should be dirtied after cifs_close is called (on the last open file
> > >handle).
> > >
> > I found it ...
> >
> > cifs exports flush, filp_close calls flush (before calling close)
> >
> > cifs_flush calls filemap_fdatawrite
> >
> > May be a case in which filemap_fdatawrite returns before the write(s) is
> > sent to the vfs and write races with close (although cifs will defer a
> > file close if a write is pending on that handle)?
>
> Steve,
>
> Here's a comment I found in the NFSv4 code.... might be relevent.
>
> >From /usr/src/linux/fs/nfs/nfs4proc.c
>
> /*
> * It is possible for data to be read/written from a mem-mapped file
> * after the sys_close call (which hits the vfs layer as a flush).
> * This means that we can't safely call nfsv4 close on a file until
> * the inode is cleared.
That comment needs updating.
In a nutshell the rules are:
- The vm_area_struct (vma) that describes the mmapped area
holds a reference to the struct file that was used in the call
to do_mmap().
- Once the the vma that referenced your struct file has been
destroyed (usually via a call to munmap() or via the call to
mmput() when the task is destroyed), the reference to the struct
file is released in the usual way, via a call to fput().
Note that once the last reference to the struct file disappears, the
filesystem is notified by a call to filp->f_op->release().
Once all the struct file that refer to any given inode have been
released, you should be able to assume that no-one is reading or writing
to its pages (other than perhaps the CIFS client itself?).
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
