Re: [PATCH] zerocopy NFS updated

[Hirokazu Takahashi]

Hi,

I wondered if regular truncate() and read() might have the same
problem, so I tested again and again.
And I realized it will occur on any local filesystems.
Sometime I could get partly zero filled data instead of file contents.

I analysis this situation, read systemcall doesn't lock anything
 -- no page lock, no semaphore lock --  while someone truncates
files partially. 
It will often happens in case of pagefault in copy_user() to
copy file data to user space.

I guess if needed, it should be fixed in VFS.

davem> Consider truncate() to 1 byte left in that page.  To handle mmap()'s
davem> of this file the kernel will memset() rest of the page to zero.
davem> 
davem> Now, in the sendfile() case the NFS client sees some page filled
davem> mostly of zeros instead of file contents.
davem> 
davem> In sendmsg() knfd case, client sees something reasonable.  He will
davem> see something that was actually in the file at some point in time.
davem> The sendfile() case sees pure garbage, contents that never were in
davem> the file at any point in time.
davem> 
davem> We could make knfsd take the write semaphore on the inode until client
davem> is known to get the packet but that is the kind of overhead we'd like
davem> to avoid.

Thank you,
Hirokazu Takahashi.