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.
-
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/
This archive was generated by hypermail 2b29 : Mon Apr 15 2002 - 22:00:20 EST