From: Frank van Maarseveen <frankvm@frankvm.com>
To: Linux NFS mailing list <nfs@lists.sourceforge.net>
Subject: RFC: nlmclnt_grant() address check vs. callback address binding
Date: Mon, 2 Jul 2007 17:49:18 +0200 [thread overview]
Message-ID: <20070702154918.GA543@janus> (raw)
Occasionally an NFS server needs to create an RPC transport for client
callbacks, e.g. when granting a blocked lock request. When a server
has multiple IP addresses (multihomed/multiple NICs or on a single
interface) then the client may be called back from a different address
because the server is free to select one: xs_udp_connect_worker() and
xs_tcp_connect_worker() call xs_bindresvport() only when a reserved port
is requested and xs_bindresvport() implicitly uses INADDR_ANY.
Currently this breaks locking when the server has more than one IP address
reachable from the client because nlmclnt_grant() on the client rejects
GRANT_MSG when the source IP address doesn't match the destination
address in the original request. This is happening in a real-world
situation where NFS servers have been virtualized using different IP
addresses on a single machine.
Basically there are two ways to fix this:
1. server callbacks should bind to a local address, not INADDR_ANY.
2. clients should accept callbacks from a different server address.
At first I thought fixing the server is the right thing to do because
the server behavior is arguably incorrect. Not easy but certainly doable
(I'd do it if it has a chance of being accepted). It might also help
NATting NFS traffic in some cases. However:
- I'm not sure if an address check such as in nlmclnt_grant()
is actually buying us anything.
- clients requiring a correct callback src address might not
work with other NFS server implementations and/or (future?)
concepts for clustering/load balancing.
- Multiple IP addresses may be a workaround for reserved port
shortage.
As it currently stands, mounting from a secondary server IP address is
broken w.r.t. locking when both client and server run linux.
Any opinion about (1) and (2)? maybe we should do both?
Currently I use (2) as a workaround:
--- a/fs/lockd/clntlock.c 2007-02-27 22:55:27.000000000 +0100
+++ b/fs/lockd/clntlock.c 2007-07-02 17:36:29.000000000 +0200
@@ -124,8 +124,15 @@ __be32 nlmclnt_grant(const struct sockad
*/
if (fl_blocked->fl_u.nfs_fl.owner->pid != lock->svid)
continue;
- if (!nlm_cmp_addr(&block->b_host->h_addr, addr))
- continue;
+ /*
+ * The granted message may come from a different IP address
+ * when the server has more than one. Warn when debug is on.
+ */
+ if (!nlm_cmp_addr(&block->b_host->h_addr, addr)) {
+ dprintk("nlmclnt_grant: "NIPQUAD_FMT" != "NIPQUAD_FMT"\n",
+ NIPQUAD(block->b_host->h_addr.sin_addr.s_addr),
+ NIPQUAD(addr->sin_addr.s_addr));
+ }
if (nfs_compare_fh(NFS_FH(fl_blocked->fl_file->f_path.dentry->d_inode) ,fh) != 0)
continue;
/* Alright, we found a lock. Set the return status
--
Frank
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next reply other threads:[~2007-07-02 15:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-02 15:49 Frank van Maarseveen [this message]
2007-07-03 1:04 ` RFC: nlmclnt_grant() address check vs. callback address binding Trond Myklebust
2007-07-03 7:01 ` Frank van Maarseveen
2007-07-03 12:03 ` Trond Myklebust
2007-07-03 20:47 ` Frank van Maarseveen
2007-07-03 21:32 ` Trond Myklebust
2007-07-03 20:33 ` J. Bruce Fields
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=20070702154918.GA543@janus \
--to=frankvm@frankvm.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.