gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] gluster doesn't like Oracle's FSINFO RPC call


From: Niels de Vos
Subject: Re: [Gluster-devel] gluster doesn't like Oracle's FSINFO RPC call
Date: Fri, 12 Apr 2013 17:23:08 +0200
User-agent: Mutt/1.5.20 (2009-12-10)

On Thu, Apr 11, 2013 at 12:37:30PM -0400, Michael Brown wrote:
> That actually broke everything (including Linux trying to mount NFS).
> 
> I've modified it slightly to be:
> 
> bool_t
> xdr_nfs_fh3 (XDR *xdrs, nfs_fh3 *objp)
> {
>         if (!xdr_bytes (xdrs, (char **)&objp->data.data_val, (u_int *)
> &objp->data.data_len, NFS3_FHSIZE))
>                 if (!xdr_opaque (xdrs, &objp, (u_int *)
> &objp->data.data_len))
>                         return FALSE;
>         return TRUE;
> }
> 
> (i.e. only call the xdr_opaque function if the xdr_bytes decode fails)

Nah, that won't work. The xdr_* functions are modifying the position of 
the cursor in the XDR-stream. Subsequent reads will continue where the 
previous one finished.

What you probably need to do is something like this:

xdr_nfs_fh3 (XDR *xdrs, nfs_fh3 *objp)
{
        uint32_t size;

        if (!xdr_int (xdrs, &size))
                if (!xdr_opaque (xdrs, (u_int *)&objp->data.data_len, size))
                        return FALSE
        return TRUE;
}

That will read the size of the fhandle first, to determine how long the opaque 
fhandle is, and use that size to read it.

Cheers,
Niels

> 
> But I get no change in behaviour.
> 
> Also get these warnings:
> 
> xdr-nfs3.c: In function 'xdr_nfs_fh3':
> xdr-nfs3.c:197: warning: passing argument 2 of 'xdr_opaque' from
> incompatible pointer type
> /usr/include/rpc/xdr.h:313: note: expected 'caddr_t' but argument is of
> type 'struct nfs_fh3 **'
> xdr-nfs3.c:197: warning: passing argument 3 of 'xdr_opaque' makes
> integer from pointer without a cast
> /usr/include/rpc/xdr.h:313: note: expected 'u_int' but argument is of
> type 'u_int *'
> 
> M.
> 
> On 13-04-11 07:42 AM, Niels de Vos wrote:
> > My guess is that this (untested) change would fix it, can you try that?
> >
> > --- a/rpc/xdr/src/xdr-nfs3.c
> > +++ b/rpc/xdr/src/xdr-nfs3.c
> > @@ -184,7 +184,7 @@ xdr_specdata3 (XDR *xdrs, specdata3 *objp)
> >  bool_t
> >  xdr_nfs_fh3 (XDR *xdrs, nfs_fh3 *objp)
> >  {
> > -    if (!xdr_bytes (xdrs, (char **)&objp->data.data_val, (u_int *) 
> > &objp->data.data_len, NFS3_FHSIZE))
> > +    if (!xdr_opaque (xdrs, &objp, (u_int *) &objp->data.data_len))
> >              return FALSE;
> >     return TRUE;
> >  }
> >
> >
> > HTH,
> > Niels
> >
> >> All I get out of gluster is:
> >> [2013-04-08 12:54:32.206312] E [nfs3.c:4741:nfs3svc_fsinfo] 0-nfs-nfsv3:
> >> Error decoding arguments
> >>
> >>
> >> I've attached abridged packet captures and text explanations of the
> >> packets (thanks to wireshark).
> >>
> >> Can someone please look at this and determine if it's gluster's parsing
> >> of the RPC call to blame, or if it's Oracle?
> >>
> >> This is the same setup on which I reported the NFS race condition bug.
> >> It does have that patch applied.
> >> Details:
> >> http://lists.gnu.org/archive/html/gluster-devel/2013-04/msg00014.html
> >>
> >> Thanks,
> >>
> >> Michael
> >>
> >> -- 
> >> Michael Brown               | `One of the main causes of the fall of
> >> Systems Consultant          | the Roman Empire was that, lacking zero,
> >> Net Direct Inc.             | they had no way to indicate successful
> >> ?: +1 519 883 1172 x5106    | termination of their C programs.' - Firth
> >>
> >
> >
> >
> >
> >> _______________________________________________
> >> Gluster-devel mailing list
> >> address@hidden
> >> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> >
> 
> 
> -- 
> Michael Brown               | `One of the main causes of the fall of
> Systems Consultant          | the Roman Empire was that, lacking zero,
> Net Direct Inc.             | they had no way to indicate successful
> ☎: +1 519 883 1172 x5106    | termination of their C programs.' - Firth
> 

-- 
Niels de Vos
Sr. Software Maintenance Engineer
Support Engineering Group
Red Hat Global Support Services



reply via email to

[Prev in Thread] Current Thread [Next in Thread]