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/