All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Russell King <rmk@arm.linux.org.uk>,
	Hubert Mantel <mantel@suse.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: Compatibility issue with 2.2.19pre7
Date: 11 Jan 2001 16:28:28 +0100	[thread overview]
Message-ID: <shszogy2jmr.fsf@charged.uio.no> (raw)
In-Reply-To: <20010110013755.D13955@suse.de> <200101100654.f0A6sjJ02453@flint.arm.linux.org.uk> <20010110163158.F19503@athlon.random>
In-Reply-To: Andrea Arcangeli's message of "Wed, 10 Jan 2001 16:31:58 +0100"

>>>>> " " == Andrea Arcangeli <andrea@suse.de> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2001-01-11 15:28 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-10  0:37 Compatibility issue with 2.2.19pre7 Hubert Mantel
2001-01-10  0:43 ` Alan Cox
2001-01-10  6:54 ` Russell King
2001-01-10 15:31   ` Andrea Arcangeli
2001-01-10 22:09     ` Russell King
2001-01-10 23:59       ` Andrea Arcangeli
2001-01-11  7:34         ` Russell King
2001-01-11 10:33           ` Andi Kleen
2001-01-11 10:36             ` Russell King
2001-01-11 12:10           ` Manfred
2001-01-11 12:10             ` Andi Kleen
2001-01-11 12:29               ` Manfred
2001-01-11 13:27                 ` Russell King
2001-01-24  7:51         ` Richard Henderson
2001-01-24  9:02           ` Andrea Arcangeli
2001-01-24  9:51             ` Richard Henderson
2001-01-24 12:21               ` Andrea Arcangeli
2001-01-24 17:49                 ` Richard Henderson
2001-01-24 10:09             ` Thomas Pornin
2001-01-11 15:28     ` Trond Myklebust [this message]
2001-01-11 16:19       ` Manfred Spraul
2001-01-11 17:44         ` Trond Myklebust
2001-01-11 18:22           ` Trond Myklebust
2001-01-11 18:27             ` Andrea Arcangeli
2001-01-11 18:30               ` Trond Myklebust
2001-01-11 18:43                 ` Andrea Arcangeli
2001-01-11 20:09                   ` Russell King
2001-01-11 20:39                   ` Trond Myklebust
2001-01-11 11:37   ` Trond Myklebust
  -- strict thread matches above, loose matches on Subject: below --
2001-01-24 13:46 Jesse Pollard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=shszogy2jmr.fsf@charged.uio.no \
    --to=trond.myklebust@fys.uio.no \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mantel@suse.de \
    --cc=rmk@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.