svc_process and nfsd_proc_read not taking checksum into account when calling svc_reserve

[Jeff Layton <jlayton@redhat.com>]

I think I've finally chased down a bug that I noticed at connectathon 
this year. When a client mounts a Linux NFS server using NFSv2 or 3 with 
sec=krb5i, the server gets a ton of messages like this in the logs:

RPC request reserved 80 but used 124

The sizes vary here, but usually the "used" is 44 bytes off from what 
was reserved (sometimes a little less). The issue seems to be that after 
writing out the response header, svc_process() calls this:

         /* un-reserve some of the out-queue now that we have a
          * better idea of reply size
          */
         if (procp->pc_xdrressize)
                 svc_reserve(rqstp, procp->pc_xdrressize<<2);

...but, this does not take into account the size of the checksum at the 
end of the response. This is also a problem in the svc_reserve calls 
made from nfsd3_proc_read and nfsd_proc_read.

While I haven't checked it, my guess is that this is also a problem for 
krb5p and for spkm3i too. We don't seem to see this issue with NFSv4, 
but I think that's because the reserved size for a compound packet is 
likely large enough to paper over this problem.

My thinking is that we need a wrapper of some sort around these calls to 
svc_reserve that increases the "space" parameter by the amount of the 
expected checksum. My question is -- is there a simple way to compute 
the expected length of the checksum, given a svc_rqst?

Thanks,
Jeff


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs