From: Ben Greear <greearb@candelatech.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Can you specify a local IP or Interface to be used on a per NFS mount basis?
Date: Thu, 19 Jan 2006 20:26:47 -0800 [thread overview]
Message-ID: <43D06687.2050108@candelatech.com> (raw)
In-Reply-To: <1137644698.8864.8.camel@lade.trondhjem.org>
Trond Myklebust wrote:
> On Wed, 2006-01-18 at 19:28 -0800, Ben Greear wrote:
>
>
>>>As David said, the place to fix it is in xs_bindresvport(), but there is
>>>no support for passing this sort of information through the current NFS
>>>binary mount structure. You would have to hack that up yourself.
>>
>>I can think of some horrible hacks to grab info out of a text file based
>>on the mount point or some other available info...but if I actually
>>attempted to do it right..would you consider the patch for kernel
>>inclusion? Is it OK to modify the binary mount structure?
>
>
> It is possible, yes: the binary structure carries a version number that
> allows the kernel to distinguish the various revisions that the userland
> mount program supports.
>
> That said, the concensus at the moment appears to be that we should move
> towards a text-based mount structure for NFS (like most of the other
> filesystems have, and like NFSroot has) so I'd be reluctant to take
> patches that define new binary structures.
Ok. This patch does extend the binary struct, and to do it really right,
we should probably pass in some sort of in_addr struct instead of the
single 'u32' for the IP address.
So, please just consider this a proof of concept. That said, with a
patched 'mount' binary (diff available if anyone cares), this does
do exactly what I want: allows binding an nfs client to a particular
local IP address.
If/when you get the text based interface working, I will try to cook
up an official patch worthy of inclusion if you have not already
done so.
This patch was inspired by a patch sent to me by: Dimitris Michailidis
Thanks,
Ben
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -407,6 +407,12 @@ nfs_create_client(struct nfs_server *ser
__FUNCTION__, PTR_ERR(xprt));
return (struct rpc_clnt *)xprt;
}
+
+ if (data->local_ip != 0) {
+ printk("nfs: Configuring local ip address as: 0x%x\n",
+ data->local_ip);
+ }
+ xprt->local_address = data->local_ip; /* specify local IP address */
clnt = rpc_create_client(xprt, server->hostname, &nfs_program,
server->rpc_ops->version, data->pseudoflavor);
if (IS_ERR(clnt)) {
@@ -1663,6 +1669,7 @@ static struct super_block *nfs_get_sb(st
deactivate_super(s);
return ERR_PTR(error);
}
+
s->s_flags |= MS_ACTIVE;
return s;
out_rpciod_down:
diff --git a/fs/super.c b/fs/super.c
diff --git a/include/linux/nfs_mount.h b/include/linux/nfs_mount.h
--- a/include/linux/nfs_mount.h
+++ b/include/linux/nfs_mount.h
@@ -20,7 +20,7 @@
* mount-to-kernel version compatibility. Some of these aren't used yet
* but here they are anyway.
*/
-#define NFS_MOUNT_VERSION 6
+#define NFS_MOUNT_VERSION 7
#define NFS_MAX_CONTEXT_LEN 256
struct nfs_mount_data {
@@ -43,6 +43,8 @@ struct nfs_mount_data {
struct nfs3_fh root; /* 4 */
int pseudoflavor; /* 5 */
char context[NFS_MAX_CONTEXT_LEN + 1]; /* 6 */
+ char pad[3]; /* 7 Align the context above */
+ unsigned int local_ip; /* 7 */
};
/* bits in the flags field */
diff --git a/include/linux/sunrpc/xprt.h b/include/linux/sunrpc/xprt.h
--- a/include/linux/sunrpc/xprt.h
+++ b/include/linux/sunrpc/xprt.h
@@ -168,7 +168,8 @@ struct rpc_xprt {
reestablish_timeout;
struct work_struct connect_worker;
unsigned short port;
-
+ u32 local_address; /* local IP address to bind to */+
/*
* Disconnection of idle transports
*/
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -928,6 +928,8 @@ static int xs_bindresvport(struct rpc_xp
int err;
unsigned short port = xprt->port;
+ myaddr.sin_addr.s_addr = xprt->local_address;
+
do {
myaddr.sin_port = htons(port);
err = sock->ops->bind(sock, (struct sockaddr *) &myaddr,
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2006-01-20 4:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-18 23:10 Can you specify a local IP or Interface to be used on a per NFS mount basis? Ben Greear
2006-01-19 0:48 ` Trond Myklebust
2006-01-19 2:21 ` Ben Greear
2006-01-19 2:29 ` David S. Miller
2006-01-19 3:24 ` Trond Myklebust
2006-01-19 3:28 ` Ben Greear
2006-01-19 4:24 ` Trond Myklebust
2006-01-20 4:26 ` Ben Greear [this message]
2006-01-20 13:52 ` Peter Staubach
2006-01-20 17:11 ` Ben Greear
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=43D06687.2050108@candelatech.com \
--to=greearb@candelatech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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;
as well as URLs for NNTP newsgroup(s).