Messages in this thread Patch in this message | | | Date | Tue, 12 Jan 1999 15:24:58 -0500 (EST) | From | David Mansfield <> | Subject | [PATCH] another knfsd reply cache bugfix |
| |
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; }
Comments?
-- /==============================\ | David Mansfield | | david@cobite.com | \==============================/
- 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/
| |