Re: [PATCH] another knfsd reply cache bugfix

H.J. Lu (hjl@lucon.org)
Thu, 28 Jan 1999 18:42:53 -0800 (PST)

>
>
> The last time I posted a patch I thought I had nailed down the problems
> with the knfsd reply cache (linux/fs/nfsd/nfscache.c). It turns out that
> while that WOULD have been a bug this one gets in the way first!
>
> The bug is this: typical usage of a 'struct svc_buf' (when adding data) is
> to advance the buf member along with incrementing the len member. For
> example, here is the svc_putlong macro (from
> linux/include/linux/sunrpc/svc.h)
>
> #define svc_putlong(resp, val) { *(resp)->buf++ = (val); (resp)->len++; }
>
> The reply cache assumes this behavior i.e. assumes that the buf pointer
> has been incremented along with all data added. However, the routines in
> linux/fs/nfsd/nfsxdr.c do not advance this pointer. In particular, it
> seems like this pointer is *not* being advanced where it could obviously
> done in xdr_ressize_check.
>
> I assumed that this pointer must be not-incremented for a reason, so I
> fixed the nfscache.c where the length calculation is done. This works for
> me, but I am unsure if a small fix to xdr_ressize_check would be more
> appropriate.
>
> Here's the diff against 2.2.0-pre7. The solution was to ignore the buf
> member (which is wrong) and look at the len member which *is* fixed up in
> xdr_ressize_check.
>
> --- linux/fs/nfsd/nfscache.c.orig Fri Jan 8 13:04:29 1999
> +++ linux/fs/nfsd/nfscache.c Tue Jan 12 08:08:56 1999
> @@ -268,8 +268,9 @@
> if (!(rp = rqstp->rq_cacherep) || cache_disabled)
> return;
>
> + len = resp->len - (statp - resp->base);
> /* Don't cache excessive amounts of data and XDR failures */
> - if (!statp || (len = resp->buf - statp) > (256 >> 2)) {
> + if (!statp || len > (256 >> 2)) {
> rp->c_state = RC_UNUSED;
> return;
> }

I saw this patch in Linux 2.2.0. But I don't think it is all correct.
Everytime when my NFS client mounts the server, the NFS server
complaints

nfsd: RC_REPLSTAT/reply len 35!
nfsd: RC_REPLSTAT/reply len 36!
nfsd: RC_REPLSTAT/reply len 20!
nfsd: RC_REPLSTAT/reply len 21!
nfsd: RC_REPLSTAT/reply len 26!

Any ideas? BTW, do you have a testcase for the bug you tried to fix?

Thanks.

H.J.

-
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/