On Fri, 2011-03-04 at 15:30 -0500, Jeff Layton wrote: > Right, I don't think we can know that since we (at the RPC layer) don't > get any real notification of when we receive a TCP ACK. > > > In this case, we're not kfree()'ing until we've gotten an rpc reply > > back. But in theory perhaps there could be cases where the server's > > gotten the data and we've seen the reply but the tcp layer still thinks > > it needs to retransmit something? I don't think we'd care if the data > > was still correct in that case, but it could be an information leak if > > nothing else. > > There's also timeouts + soft mounts to consider. We may send the data > on the socket, which gets buffered up and then the caller goes to sleep > waiting for a reply. If that never comes (server crashed or something), > then we can return an error back up to the VFS layer if it's a soft > mount. Meanwhile, the kernel is still trying to send the data on the > socket... O_DIRECT writes have a similar problem, BTW. Occasionally we do return control to userland while the pages are still buffered in the socket (either due to the above conditions, or due to the fact that we were retransmitting an RPC request, and we suddenly get a reply to the previous transmission). If the application then scribbles over the page data, the socket may end up transmitting a quite different WRITE payload than what it was supposed to... For that reason, it would be nice to have some way to know when the socket is done referencing the data. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
