From: Frank Filz <ffilzlnx@us.ibm.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: NFS List <linux-nfs@vger.kernel.org>,
libtirpc <libtirpc-devel@lists.sourceforge.net>,
Steve Dickson <SteveD@redhat.com>
Subject: Re: [PATCH] Change prognum, versnum, minvers, and maxvers in progping to u_int32_t from u_long
Date: Wed, 22 Apr 2009 15:19:12 -0700 [thread overview]
Message-ID: <1240438752.2246.20.camel@dyn9047022153> (raw)
In-Reply-To: <AEAEC6BE-769B-4027-B427-041C65BB1EF8@oracle.com>
On Wed, 2009-04-22 at 17:46 -0400, Chuck Lever wrote:
> On Apr 22, 2009, at 5:45 PM, Frank Filz wrote:
> > This fixes a problem where "rpcinfo -T transport host prognum" fails
> > on a PPC64
> > because CLNT_CONTROL expects the version number to be a 32 bit
> > quantity. u_long
> > probably works fine on little endian machines, but won't work on big
> > endian
> > machines.
>
> Hrm. These variables are unsigned long pretty much everywhere in the
> legacy RPC code. And, isn't SPARC big endian? Is the real problem
> 32- v. 64- bit?
I at first though it would be a 64/32 bit problen, but now I think it
would still affect 32 bit, since unsigned long would still be a 64 bit
quantity, with the low order 32 bits being in the 5th through 8th bytes
on big endian, and therefore the 1st through 4th bytes which will be
accessed by casting a (void *) t (int *) would be 0.
> This might be fixed more generically by adding a type cast to
> CLNT_CONTROL.
I did try a type cast at first, but it didn't work, though I might not
have done it right.
But look at these definitions from /usr/include/rpc/types.h:
/* This needs to be changed to uint32_t in the future */
typedef unsigned long rpcprog_t;
typedef unsigned long rpcvers_t;
typedef unsigned long rpcproc_t;
typedef unsigned long rpcprot_t;
typedef unsigned long rpcport_t;
Now look at the same definitions from /usr/include/tirpc/rpc/types.h:
typedef u_int32_t rpcprog_t;
typedef u_int32_t rpcvers_t;
typedef u_int32_t rpcproc_t;
typedef u_int32_t rpcprot_t;
typedef u_int32_t rpcport_t;
Actually, the patch probably should change the definitions to:
rpcprog_t prognum;
rpcvers_t versnum, minvers, maxvers;
(though internally, the CLNT_CONTROL is casting to u_int32_t, not
rpcvers_t or rpcprog_t).
It is curious though that in RFC 1833, there is this definition:
struct rpcb {
unsigned long r_prog; /* program number */
unsigned long r_vers; /* version number */
string r_netid<>; /* network id */
string r_addr<>; /* universal address */
string r_owner<>; /* owner of this service */
};
But pretty much every where else, including the RPC protocol, prog and
vers are unsigned int...
> > Signed-off-by: Frank Filz <ffilzlnx@us.ibm.com>
> > ---
> > src/rpcinfo.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/rpcinfo.c b/src/rpcinfo.c
> > index 0170f65..698f4ca 100644
> > --- a/src/rpcinfo.c
> > +++ b/src/rpcinfo.c
> > @@ -1591,7 +1591,7 @@ progping (netid, argc, argv)
> > CLIENT *client;
> > struct timeval to;
> > enum clnt_stat rpc_stat;
> > - u_long prognum, versnum, minvers, maxvers;
> > + u_int32_t prognum, versnum, minvers, maxvers;
> > struct rpc_err rpcerr;
> > int failure = 0;
> > struct netconfig *nconf;
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
next prev parent reply other threads:[~2009-04-22 22:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-22 21:45 [PATCH] Change prognum, versnum, minvers, and maxvers in progping to u_int32_t from u_long Frank Filz
2009-04-22 21:46 ` Chuck Lever
2009-04-22 22:19 ` Frank Filz [this message]
2009-04-22 21:56 ` Chuck Lever
2009-04-22 22:08 ` [Libtirpc-devel] " Chuck Lever
2009-04-22 22:36 ` [PATCH] rpcbind: Change prognum, versnum, minvers, and maxvers in progping to rpcprog_t and rpcvers_t " Frank Filz
2009-04-22 22:37 ` Chuck Lever
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=1240438752.2246.20.camel@dyn9047022153 \
--to=ffilzlnx@us.ibm.com \
--cc=SteveD@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=libtirpc-devel@lists.sourceforge.net \
--cc=linux-nfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox