Messages in this thread | | | From | (H.J. Lu) | Subject | Re: [PATCH] another knfsd reply cache bugfix | Date | 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/
| |