| Message ID | 20141109011518.8806.36904.stgit@manet.1015granger.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Chuck, It looks like this patch and the next one are general client changes, so they might have to be submitted to Trond directly rather than going through my tree. Trond, what do you think? Anna On 11/08/2014 08:15 PM, Chuck Lever wrote: > Use the correct calculation of the maximum size of a clientaddr4 > when encoding and decoding SETCLIENTID operations. clientaddr4 is > defined in section 2.2.10 of RFC3530bis-31. > > The usage in encode_setclientid_maxsz is missing the 4-byte length > in both strings, but is otherwise correct. decode_setclientid_maxsz > simply asks for a page of receive buffer space, which is > unnecessarily large (more than 4KB). > > Note that a SETCLIENTID reply is either clientid+verifier, or > clientaddr4, depending on the returned NFS status. It doesn't > hurt to allocate enough space for both. > > Signed-off-by: Chuck Lever <chuck.lever@oracle.com> > --- > fs/nfs/nfs4xdr.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c > index 206c08a..f8afa67 100644 > --- a/fs/nfs/nfs4xdr.c > +++ b/fs/nfs/nfs4xdr.c > @@ -141,13 +141,15 @@ static int nfs4_stat_to_errno(int); > XDR_QUADLEN(NFS4_VERIFIER_SIZE) + \ > XDR_QUADLEN(NFS4_SETCLIENTID_NAMELEN) + \ > 1 /* sc_prog */ + \ > - XDR_QUADLEN(RPCBIND_MAXNETIDLEN) + \ > - XDR_QUADLEN(RPCBIND_MAXUADDRLEN) + \ > + 1 + XDR_QUADLEN(RPCBIND_MAXNETIDLEN) + \ > + 1 + XDR_QUADLEN(RPCBIND_MAXUADDRLEN) + \ > 1) /* sc_cb_ident */ > #define decode_setclientid_maxsz \ > (op_decode_hdr_maxsz + \ > - 2 + \ > - 1024) /* large value for CLID_INUSE */ > + 2 /* clientid */ + \ > + XDR_QUADLEN(NFS4_VERIFIER_SIZE) + \ > + 1 + XDR_QUADLEN(RPCBIND_MAXNETIDLEN) + \ > + 1 + XDR_QUADLEN(RPCBIND_MAXUADDRLEN)) > #define encode_setclientid_confirm_maxsz \ > (op_encode_hdr_maxsz + \ > 3 + (NFS4_VERIFIER_SIZE >> 2)) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 10, 2014 at 10:22 AM, Anna Schumaker <Anna.Schumaker@netapp.com> wrote: > Hi Chuck, > > It looks like this patch and the next one are general client changes, so they might have to be submitted to Trond directly rather than going through my tree. Trond, what do you think? Ditto for the iostat locking change (PATCH 08/10). None of those are RDMA related. Should I just cherrypick them from this series?
diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c index 206c08a..f8afa67 100644 --- a/fs/nfs/nfs4xdr.c +++ b/fs/nfs/nfs4xdr.c @@ -141,13 +141,15 @@ static int nfs4_stat_to_errno(int); XDR_QUADLEN(NFS4_VERIFIER_SIZE) + \ XDR_QUADLEN(NFS4_SETCLIENTID_NAMELEN) + \ 1 /* sc_prog */ + \ - XDR_QUADLEN(RPCBIND_MAXNETIDLEN) + \ - XDR_QUADLEN(RPCBIND_MAXUADDRLEN) + \ + 1 + XDR_QUADLEN(RPCBIND_MAXNETIDLEN) + \ + 1 + XDR_QUADLEN(RPCBIND_MAXUADDRLEN) + \ 1) /* sc_cb_ident */ #define decode_setclientid_maxsz \ (op_decode_hdr_maxsz + \ - 2 + \ - 1024) /* large value for CLID_INUSE */ + 2 /* clientid */ + \ + XDR_QUADLEN(NFS4_VERIFIER_SIZE) + \ + 1 + XDR_QUADLEN(RPCBIND_MAXNETIDLEN) + \ + 1 + XDR_QUADLEN(RPCBIND_MAXUADDRLEN)) #define encode_setclientid_confirm_maxsz \ (op_encode_hdr_maxsz + \ 3 + (NFS4_VERIFIER_SIZE >> 2))
Use the correct calculation of the maximum size of a clientaddr4 when encoding and decoding SETCLIENTID operations. clientaddr4 is defined in section 2.2.10 of RFC3530bis-31. The usage in encode_setclientid_maxsz is missing the 4-byte length in both strings, but is otherwise correct. decode_setclientid_maxsz simply asks for a page of receive buffer space, which is unnecessarily large (more than 4KB). Note that a SETCLIENTID reply is either clientid+verifier, or clientaddr4, depending on the returned NFS status. It doesn't hurt to allocate enough space for both. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> --- fs/nfs/nfs4xdr.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html