I saw your post on the NFS patch (below), but I was looking over the
Sun RPC code in order to better understand how to use the kernel socket
services. Because what I want to do uses TCP, I was closely examining
the TCP Sun RPC code. I've either found some problems or I *really*
don't understand how this works (I'm willing to believe either).
I've focused my attention in net/sunrpc/svcsock.c and here's what I'm
having problems with:
1. In the function svc_tcp_recvfrom() there is a call to
svc_recv_available
which returns the number of bytes currently available on the socket.
It checks to see if the value returned is < the size of the record,
if
there are not enough bytes yet to make a complete record it sets len
to -EAGAIN, however, it falls through to svc_recvfrom() and loses
this
information because it resets len with the amount read from the
socket.
If I'm interpreting this right, there is the potential for partial
packets to cause garbage to appear at the end of the RPC packet. If
this is correct, this could be solved by having a "goto error" after
len is set to -EAGAIN.
2. I think this one is a little more subtle and I'm not sure if RPCs get
"batched" into a single TCP packet. If they do here's the problem:
The code in svc_tcp_recvfrom() reads the first RPC header from the
socket. It then reads the amount of data indicated by the record
length (there may be another issue here -- what if the record length
is greater than the buffer -- I *think* there won't be data over-runs
but you've only captured part of the RPC request). It then clears
the idea that it has data (by calling svc_sock_received() wich
decrements
the sk_data field). So if we assume that there were two RPC requests
in a single TCP packet, we still have the second RPC request on the
socket, but no indication that there is any data on the socket.
There
is no code that ensures that there is no remaining data on the socket
when it resets the sk_data flag.
I would greatly appreciate it if you could let me know if my analysis is
correct or if I'm mis-understanding something. Again, I don't have any
tests that illustrate this, it was just what I found reading over the
code.
BTW I haven't looked at 2.2.0pre-x code but as of 2.1.131 the above was
true.
Thanks.
TTFN - Guy
"G. Allen Morris III" wrote:
>
> When I was trying to write `large' files over TCP NFS I was
> getting `bad TCP reclen' errors.
>
> The patch below gets rid of that problem.
> ------------------ patch ---------------------
> diff -u linux-2.2.0-pre2/net/sunrpc/svcsock.c linux/net/sunrpc/svcsock.c
> --- linux-2.2.0-pre2/net/sunrpc/svcsock.c Thu Nov 12 08:33:29 1998
> +++ linux/net/sunrpc/svcsock.c Sat Jan 2 10:34:15 1999
> @@ -635,8 +635,11 @@
> if (len < svsk->sk_reclen) {
> dprintk("svc: incomplete TCP record (%d of %ld)\n",
> len, svsk->sk_reclen);
> +#if 0
> svc_sock_received(svsk, ready);
> +#endif
> len = -EAGAIN; /* record not complete */
> + goto error;
> }
>
> /* Frob argbuf */
> diff -u linux-2.2.0-pre2/fs/nfsd/nfssvc.c linux/fs/nfsd/nfssvc.c
> --- linux-2.2.0-pre2/fs/nfsd/nfssvc.c Fri Jan 1 23:03:09 1999
> +++ linux/fs/nfsd/nfssvc.c Fri Jan 1 22:57:41 1999
> @@ -76,7 +76,7 @@
> if (error < 0)
> goto failure;
>
> -#if 0 /* Don't even pretend that TCP works. It doesn't. */
> +#if 1 /* Pretend that TCP works. It might. */
> error = svc_makesock(serv, IPPROTO_TCP, port);
> if (error < 0)
> goto failure;
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/