>>>>> " " == Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> As far I can see the only reason size makes sense to be 32bit
> is to get some more strict behaviour in the below code (to
> avoid discarding the most significant 16bits in sanity checks
> like this):
> nlm4_decode_fh(u32 *p, struct nfs_fh *f) {
> memset(f->data, 0, sizeof(f->data));
> f-> size = ntohl(*p++);
> if (f->size > NFS_MAXFHSIZE) {
> printk(KERN_NOTICE
> "lockd: bad fhandle size %d (should be
> <=%d)\n",
> f-> size, NFS_MAXFHSIZE);
> return NULL;
> }
> memcpy(f->data, p, f->size);
> return p + XDR_QUADLEN(f->size);
> }
I agree, and if that's the only problem, then the appended patch will
fix it without any need to change struct nfs_fh.
As for the issue of casting 'fh->data' as a 'struct knfsd' then that
is a perfectly valid operation.
The fh->data is a cookie as far as the client is concerned, and hence
it will pass back exactly whatever the server sent it (alignment and
all).
IOW: the knfsd server copied a struct knfsd and sent it off to the
client, and now the exact same server is receiving a completely
unadulterated version of said struct knfsd for use by the lockd server
routines.
Unless somebody is using one compiler for the knfsd directory and then
a completely different one for lockd, I fail to see why this should
result in structure alignment problems on PPC or on any other
platform.
Cheers,
Trond
--- fs/lockd/xdr4.c.orig Thu Jan 11 15:52:44 2001
+++ fs/lockd/xdr4.c Thu Jan 11 15:53:37 2001
@@ -83,16 +83,19 @@
static u32 *
nlm4_decode_fh(u32 *p, struct nfs_fh *f)
{
+ unsigned int size;
+
memset(f->data, 0, sizeof(f->data));
- f->size = ntohl(*p++);
- if (f->size > NFS_MAXFHSIZE) {
+ size = ntohl(*p++);
+ if (size > NFS_MAXFHSIZE) {
printk(KERN_NOTICE
"lockd: bad fhandle size %x (should be %d)\n",
- f->size, NFS_MAXFHSIZE);
+ size, NFS_MAXFHSIZE);
return NULL;
}
- memcpy(f->data, p, f->size);
- return p + XDR_QUADLEN(f->size);
+ f->size = size;
+ memcpy(f->data, p, size);
+ return p + XDR_QUADLEN(size);
}
static u32 *
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
