All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
Cc: nfs@lists.sourceforge.net
Subject: Re: [RFC] [PATCH] rpcbind netid declared per-transport
Date: Fri, 31 Aug 2007 10:08:56 -0400	[thread overview]
Message-ID: <46D820F8.6040309@oracle.com> (raw)
In-Reply-To: <EXNANE01Mb1s7nlT2Nq00000219@exnane01.hq.netapp.com>

[-- Attachment #1: Type: text/plain, Size: 5127 bytes --]

Talpey, Thomas wrote:
> The following patch moves rpcbind v3 "netid" selection from the
> rpbcind client to the originating transport, where I believe it belongs.
> This also enables IPv6 rpcbind transport resolution by the client.
> 
> Patch base is 2.6.23-rc4 + Trond NFS_ALL.
> 
> Comments?
> 
> Tom.
> 
> -----
> 
> SUNRPC: export per-transport netid's
> 
> The rpcbind (v3+) netid is provided by each RPC client transport.
> This enables IPv6 rpcbind client support, and future extension.

More clear: "This fixes an omission with IPv6 rpcbind client support."

"Enables" suggests there's nothing more to do to make IPv6 work.

> Signed-off-by: Tom Talpey <tmt@netapp.com>
> 
> ---
> 
>  include/linux/sunrpc/clnt.h |    8 ++++++++
>  include/linux/sunrpc/xprt.h |    1 +
>  net/sunrpc/rpcb_clnt.c      |   24 +++++++++---------------
>  net/sunrpc/xprtsock.c       |   10 ++++++++++
>  4 files changed, 28 insertions(+), 15 deletions(-)
> 
> Index: linux-2.6.22/include/linux/sunrpc/xprt.h
> ===================================================================
> --- linux-2.6.22.orig/include/linux/sunrpc/xprt.h
> +++ linux-2.6.22/include/linux/sunrpc/xprt.h
> @@ -56,6 +56,7 @@ enum rpc_display_format_t {
>  	RPC_DISPLAY_HEX_ADDR,
>  	RPC_DISPLAY_HEX_PORT,
>  	RPC_DISPLAY_UNIVERSAL_ADDR,
> +	RPC_DISPLAY_NETID,
>  	RPC_DISPLAY_MAX,
>  };
>  
> Index: linux-2.6.22/net/sunrpc/xprtsock.c
> ===================================================================
> --- linux-2.6.22.orig/net/sunrpc/xprtsock.c
> +++ linux-2.6.22/net/sunrpc/xprtsock.c
> @@ -337,6 +337,11 @@ static void xs_format_ipv4_peer_addresse
>  				ntohs(addr->sin_port) & 0xff);
>  	}
>  	xprt->address_strings[RPC_DISPLAY_UNIVERSAL_ADDR] = buf;
> +
> +	if (xprt->prot == IPPROTO_UDP)
> +		xprt->address_strings[RPC_DISPLAY_NETID] = RPCB_NETID_UDP;
> +	else
> +		xprt->address_strings[RPC_DISPLAY_NETID] = RPCB_NETID_TCP;
>  }
>  
>  static void xs_format_ipv6_peer_addresses(struct rpc_xprt *xprt)
> @@ -398,6 +403,11 @@ static void xs_format_ipv6_peer_addresse
>  				ntohs(addr->sin6_port) & 0xff);
>  	}
>  	xprt->address_strings[RPC_DISPLAY_UNIVERSAL_ADDR] = buf;
> +
> +	if (xprt->prot == IPPROTO_UDP)
> +		xprt->address_strings[RPC_DISPLAY_NETID] = RPCB_NETID_UDP6;
> +	else
> +		xprt->address_strings[RPC_DISPLAY_NETID] = RPCB_NETID_TCP6;
>  }
>  
>  static void xs_free_peer_addresses(struct rpc_xprt *xprt)
> Index: linux-2.6.22/net/sunrpc/rpcb_clnt.c
> ===================================================================
> --- linux-2.6.22.orig/net/sunrpc/rpcb_clnt.c
> +++ linux-2.6.22/net/sunrpc/rpcb_clnt.c
> @@ -95,20 +95,9 @@ enum {
>  /*
>   * r_netid
>   *
> - * Quoting RFC 3530, section 2.2:
> - *
> - * For TCP over IPv4 the value of r_netid is the string "tcp".  For UDP
> - * over IPv4 the value of r_netid is the string "udp".
> - *
> - * ...
> - *
> - * For TCP over IPv6 the value of r_netid is the string "tcp6".  For UDP
> - * over IPv6 the value of r_netid is the string "udp6".
> + * Note that RFC 1833 does not put any size restrictions on the
> + * netid string, but all currently defined netid's fit in 4 bytes.
>   */
> -#define RPCB_NETID_UDP	"\165\144\160"		/* "udp" */
> -#define RPCB_NETID_TCP	"\164\143\160"		/* "tcp" */
> -#define RPCB_NETID_UDP6	"\165\144\160\066"	/* "udp6" */
> -#define RPCB_NETID_TCP6	"\164\143\160\066"	/* "tcp6" */
>  
>  #define RPCB_MAXNETIDLEN	(4u)

Actually I would keep RPCB_MAXNETIDLEN with the RPCB_NETID definitions 
in the header file.

> @@ -408,8 +397,13 @@ void rpcb_getport_async(struct rpc_task 
>  	map->r_prot = xprt->prot;
>  	map->r_port = 0;
>  	map->r_xprt = xprt_get(xprt);
> -	map->r_netid = (xprt->prot == IPPROTO_TCP) ? RPCB_NETID_TCP :
> -						   RPCB_NETID_UDP;
> +	map->r_netid = rpc_peeraddr2str(clnt, RPC_DISPLAY_NETID);
> +	if (strlen(map->r_netid) > RPCB_MAXNETIDLEN) {
> +		status = -ENAMETOOLONG;
> +		dprintk("RPC: %5u %s: netid %s too long (%d)\n",
> +			task->tk_pid, __FUNCTION__, map->r_netid, RPCB_MAXNETIDLEN);
> +		goto bailout;
> +	}
 >
>  	memcpy(&map->r_addr,
>  	       rpc_peeraddr2str(rpcb_clnt, RPC_DISPLAY_UNIVERSAL_ADDR),
>  	       sizeof(map->r_addr));
> Index: linux-2.6.22/include/linux/sunrpc/clnt.h
> ===================================================================
> --- linux-2.6.22.orig/include/linux/sunrpc/clnt.h
> +++ linux-2.6.22/include/linux/sunrpc/clnt.h
> @@ -92,6 +92,14 @@ struct rpc_procinfo {
>  	char *			p_name;		/* name of procedure */
>  };
>  
> +/*
> + * RFC1833/RFC3530 rpcbind (v3+) well-known netid's.
> + */
> +#define	RPCB_NETID_UDP	"\165\144\160"		/* "udp" */
> +#define	RPCB_NETID_TCP	"\164\143\160"		/* "tcp" */
> +#define	RPCB_NETID_UDP6	"\165\144\160\066"	/* "udp6" */
> +#define	RPCB_NETID_TCP6	"\164\143\160\066"	/* "tcp6" */
> +
>  #ifdef __KERNEL__
>  
>  struct rpc_create_args {

IMO this is the wrong header to use for these definitions.

clnt.h is for internal definitions that are specific to the Linux RPC 
client implementation.  msg_prot.h is for definitions that are specified 
by the relevant RFCs.  I think the NETID values fall in the latter 
category and thus belong in msg_prot.h

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2007-08-31 14:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-31 13:35 [RFC] [PATCH] rpcbind netid declared per-transport Talpey, Thomas
2007-08-31 14:08 ` Chuck Lever [this message]
2007-08-31 14:26   ` Trond Myklebust
2007-08-31 14:30     ` Chuck Lever
2007-08-31 15:13       ` Trond Myklebust
2007-08-31 15:38         ` Chuck Lever
2007-08-31 16:08           ` Talpey, Thomas
2007-08-31 16:27             ` Chuck Lever
2007-08-31 16:41               ` Talpey, Thomas
2007-08-31 16:59                 ` Chuck Lever
2007-08-31 14:33     ` Chuck Lever
2007-08-31 14:32 ` 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=46D820F8.6040309@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=Thomas.Talpey@netapp.com \
    --cc=nfs@lists.sourceforge.net \
    /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.