2008-07-03 21:14:35

by [email protected]

[permalink] [raw]
Subject: Re: [PATCH 1/8] SUNRPC: Add address family field to svc_serv data structure

On Mon, Jun 30, 2008 at 06:45:30PM -0400, Chuck Lever wrote:
> Introduce and initialize an address family field in the svc_serv structure.
>
> This field will determine what family to use for the service's listener
> sockets and what families are advertised via the local rpcbind daemon.

Possibly dumb question: so it never makes sense to listen on sockets
with both address families?

--b.

>
> Signed-off-by: Chuck Lever <[email protected]>
> ---
>
> fs/lockd/svc.c | 2 +-
> fs/nfs/callback.c | 3 ++-
> fs/nfsd/nfssvc.c | 1 +
> include/linux/sunrpc/svc.h | 7 ++++---
> net/sunrpc/svc.c | 11 ++++++-----
> 5 files changed, 14 insertions(+), 10 deletions(-)
>
>
> diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
> index 2169af4..51bccee 100644
> --- a/fs/lockd/svc.c
> +++ b/fs/lockd/svc.c
> @@ -276,7 +276,7 @@ lockd_up(int proto) /* Maybe add a 'family' option when IPv6 is supported ?? */
> "lockd_up: no pid, %d users??\n", nlmsvc_users);
>
> error = -ENOMEM;
> - serv = svc_create(&nlmsvc_program, LOCKD_BUFSIZE, NULL);
> + serv = svc_create(&nlmsvc_program, LOCKD_BUFSIZE, AF_INET, NULL);
> if (!serv) {
> printk(KERN_WARNING "lockd_up: create service failed\n");
> goto out;
> diff --git a/fs/nfs/callback.c b/fs/nfs/callback.c
> index f447f4b..6a09760 100644
> --- a/fs/nfs/callback.c
> +++ b/fs/nfs/callback.c
> @@ -105,7 +105,8 @@ int nfs_callback_up(void)
> mutex_lock(&nfs_callback_mutex);
> if (nfs_callback_info.users++ || nfs_callback_info.task != NULL)
> goto out;
> - serv = svc_create(&nfs4_callback_program, NFS4_CALLBACK_BUFSIZE, NULL);
> + serv = svc_create(&nfs4_callback_program, NFS4_CALLBACK_BUFSIZE,
> + AF_INET, NULL);
> ret = -ENOMEM;
> if (!serv)
> goto out_err;
> diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
> index 941041f..f38f47a 100644
> --- a/fs/nfsd/nfssvc.c
> +++ b/fs/nfsd/nfssvc.c
> @@ -219,6 +219,7 @@ int nfsd_create_serv(void)
> atomic_set(&nfsd_busy, 0);
> nfsd_serv = svc_create_pooled(&nfsd_program,
> nfsd_max_blksize,
> + AF_INET,
> nfsd_last_thread,
> nfsd, SIG_NOCLEAN, THIS_MODULE);
> if (nfsd_serv == NULL)
> diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
> index 4b54c5f..a27178b 100644
> --- a/include/linux/sunrpc/svc.h
> +++ b/include/linux/sunrpc/svc.h
> @@ -66,6 +66,7 @@ struct svc_serv {
> struct list_head sv_tempsocks; /* all temporary sockets */
> int sv_tmpcnt; /* count of temporary sockets */
> struct timer_list sv_temptimer; /* timer for aging temporary sockets */
> + sa_family_t sv_family; /* listener's address family */
>
> char * sv_name; /* service name */
>
> @@ -382,13 +383,13 @@ struct svc_procedure {
> /*
> * Function prototypes.
> */
> -struct svc_serv * svc_create(struct svc_program *, unsigned int,
> - void (*shutdown)(struct svc_serv*));
> +struct svc_serv *svc_create(struct svc_program *, unsigned int, sa_family_t,
> + void (*shutdown)(struct svc_serv *));
> struct svc_rqst *svc_prepare_thread(struct svc_serv *serv,
> struct svc_pool *pool);
> void svc_exit_thread(struct svc_rqst *);
> struct svc_serv * svc_create_pooled(struct svc_program *, unsigned int,
> - void (*shutdown)(struct svc_serv*),
> + sa_family_t, void (*shutdown)(struct svc_serv *),
> svc_thread_fn, int sig, struct module *);
> int svc_set_num_threads(struct svc_serv *, struct svc_pool *, int);
> void svc_destroy(struct svc_serv *);
> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> index 01c7e31..d0e7865 100644
> --- a/net/sunrpc/svc.c
> +++ b/net/sunrpc/svc.c
> @@ -366,7 +366,7 @@ svc_pool_for_cpu(struct svc_serv *serv, int cpu)
> */
> static struct svc_serv *
> __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
> - void (*shutdown)(struct svc_serv *serv))
> + sa_family_t family, void (*shutdown)(struct svc_serv *serv))
> {
> struct svc_serv *serv;
> unsigned int vers;
> @@ -375,6 +375,7 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>
> if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
> return NULL;
> + serv->sv_family = family;
> serv->sv_name = prog->pg_name;
> serv->sv_program = prog;
> serv->sv_nrthreads = 1;
> @@ -434,21 +435,21 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>
> struct svc_serv *
> svc_create(struct svc_program *prog, unsigned int bufsize,
> - void (*shutdown)(struct svc_serv *serv))
> + sa_family_t family, void (*shutdown)(struct svc_serv *serv))
> {
> - return __svc_create(prog, bufsize, /*npools*/1, shutdown);
> + return __svc_create(prog, bufsize, /*npools*/1, family, shutdown);
> }
> EXPORT_SYMBOL(svc_create);
>
> struct svc_serv *
> svc_create_pooled(struct svc_program *prog, unsigned int bufsize,
> - void (*shutdown)(struct svc_serv *serv),
> + sa_family_t family, void (*shutdown)(struct svc_serv *serv),
> svc_thread_fn func, int sig, struct module *mod)
> {
> struct svc_serv *serv;
> unsigned int npools = svc_pool_map_get();
>
> - serv = __svc_create(prog, bufsize, npools, shutdown);
> + serv = __svc_create(prog, bufsize, npools, family, shutdown);
>
> if (serv != NULL) {
> serv->sv_function = func;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html


2008-07-04 13:45:47

by Chuck Lever III

[permalink] [raw]
Subject: Re: [PATCH 1/8] SUNRPC: Add address family field to svc_serv data structure

On Thu, Jul 3, 2008 at 5:14 PM, J. Bruce Fields <[email protected]> wrote:
> On Mon, Jun 30, 2008 at 06:45:30PM -0400, Chuck Lever wrote:
>> Introduce and initialize an address family field in the svc_serv structure.
>>
>> This field will determine what family to use for the service's listener
>> sockets and what families are advertised via the local rpcbind daemon.
>
> Possibly dumb question: so it never makes sense to listen on sockets
> with both address families?

There are several ways to map an AF_INET address to an AF_INET6
address, so you can easily set up a single AF_INET6 listener that can
also handle your AF_INET traffic.

You can listen on both, but I think having a single listener is less complex.

--
Chuck Lever