From: Chuck Lever <chuck.lever@oracle.com>
To: steved@redhat.com
Cc: chris.mason@oracle.com, linux-nfs@vger.kernel.org
Subject: [PATCH 12/24] statd: add IPv6 support in sm_notify_1_svc()
Date: Thu, 14 Jan 2010 12:30:36 -0500 [thread overview]
Message-ID: <20100114173036.26079.2923.stgit@localhost.localdomain> (raw)
In-Reply-To: <20100114172457.26079.66627.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
We have all the pieces in place, so update sm_notify_1_svc() to handle
SM_NOTIFY requests sent from IPv6 remotes.
This also eliminates a memory leak: the strdup'd memory containing the
callers' presentation address was never freed.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
utils/statd/callback.c | 69 +++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 62 insertions(+), 7 deletions(-)
diff --git a/utils/statd/callback.c b/utils/statd/callback.c
index b1acd15..d1cc139 100644
--- a/utils/statd/callback.c
+++ b/utils/statd/callback.c
@@ -10,7 +10,7 @@
#include <config.h>
#endif
-#include <arpa/inet.h>
+#include <netdb.h>
#include "rpcmisc.h"
#include "statd.h"
@@ -20,19 +20,69 @@
/* notify_list *cbnl = NULL; ... never used */
-/*
+/*
* Services SM_NOTIFY requests.
- * Any clients that have asked us to monitor that host are put on
- * the global callback list, which is processed as soon as statd
- * returns to svc_run.
+ *
+ * When NLM uses an SM_MON request to tell statd to monitor a remote,
+ * the request contains a "mon_name" argument. This is usually the
+ * "caller_name" argument of an NLMPROC_LOCK request. On Linux, the
+ * NLM can send statd the remote's IP address instead of its
+ * caller_name. The NSM protocol does not allow both the remote's
+ * caller_name and it's IP address to be sent in the same SM_MON
+ * request.
+ *
+ * The remote's caller_name is useful because it makes it simple
+ * to identify rebooting remotes by matching the "mon_name" argument
+ * they sent via an SM_NOTIFY request.
+ *
+ * The caller_name string may not be a fully qualified domain name,
+ * or even registered in the DNS database, however. Having the
+ * remote's IP address is useful because then there is no ambiguity
+ * about where to send an SM_NOTIFY after the local system reboots.
+ *
+ * Without the actual caller_name, however, statd must use an
+ * heuristic to match an incoming SM_NOTIFY request to one of the
+ * hosts it is currently monitoring. The incoming mon_name in an
+ * SM_NOTIFY address is converted to a list of IP addresses using
+ * DNS. Each mon_name on statd's monitor list is also converted to
+ * an address list, and the two lists are checked to see if there is
+ * a matching address.
+ *
+ * There are some risks to this strategy:
+ *
+ * 1. The external DNS database is not reliable. It can change
+ * over time, or the forward and reverse mappings could be
+ * inconsistent.
+ *
+ * 2. If statd's monitor list becomes substantial, finding a match
+ * can generate a not inconsequential amount of DNS traffic.
+ *
+ * 3. statd is a single-threaded service. When DNS becomes slow or
+ * unresponsive, statd also becomes slow or unresponsive.
+ *
+ * 4. If the remote does not have a DNS entry at all (or if the
+ * remote can resolve itself, but the local host can't resolve
+ * the remote's hostname), the remote cannot be monitored, and
+ * therefore NLM locking cannot be provided for that host.
+ *
+ * 5. Local DNS resolution can produce different results for the
+ * mon_name than the results the remote might see for the same
+ * query, especially if the remote did not send a caller_name
+ * or mon_name that is a fully qualified domain name.
+ *
+ * Note that a caller_name is passed from NFS client to server,
+ * but the client never knows what mon_name the server might use
+ * to notify it of a reboot. On Linux, the client extracts the
+ * server's name from the devname it was passed by the mount
+ * command. This is often not a fully-qualified domain name.
*/
void *
sm_notify_1_svc(struct stat_chge *argp, struct svc_req *rqstp)
{
notify_list *lp, *call;
static char *result = NULL;
- struct sockaddr_in *sin = nfs_getrpccaller_in(rqstp->rq_xprt);
- char *ip_addr = xstrdup(inet_ntoa(sin->sin_addr));
+ struct sockaddr *sap = nfs_getrpccaller(rqstp->rq_xprt);
+ char ip_addr[INET6_ADDRSTRLEN];
xlog(D_CALL, "Received SM_NOTIFY from %s, state: %d",
argp->mon_name, argp->state);
@@ -44,6 +94,11 @@ sm_notify_1_svc(struct stat_chge *argp, struct svc_req *rqstp)
return ((void *) &result);
}
+ if (!statd_present_address(sap, ip_addr, sizeof(ip_addr))) {
+ xlog_warn("Unrecognized sender address");
+ return ((void *) &result);
+ }
+
/* okir change: statd doesn't remove the remote host from its
* internal monitor list when receiving an SM_NOTIFY call from
* it. Lockd will want to continue monitoring the remote host
next prev parent reply other threads:[~2010-01-14 17:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-14 17:28 [PATCH 00/24] Remaining IPv6 patches for statd Chuck Lever
[not found] ` <20100114172457.26079.66627.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-01-14 17:28 ` [PATCH 01/24] libnsm.a: Add RPC construction helper functions Chuck Lever
2010-01-14 17:29 ` [PATCH 02/24] sm-notify: Replace RPC code Chuck Lever
2010-01-14 17:29 ` [PATCH 03/24] statd: Update rmtcall.c Chuck Lever
2010-01-14 17:29 ` [PATCH 04/24] sm-notify: factor socket creation out of notify() Chuck Lever
2010-01-14 17:29 ` [PATCH 05/24] sm-notify: Support creating a PF_INET6 socket in smn_create_socket() Chuck Lever
2010-01-14 17:29 ` [PATCH 06/24] sm-notify: IPv6 support in reserved port binding " Chuck Lever
2010-01-14 17:29 ` [PATCH 07/24] sm-notify: Use getaddrinfo(3) to create bind address " Chuck Lever
2010-01-14 17:30 ` [PATCH 08/24] sm-notify: Support IPv6 DNS lookups in smn_lookup Chuck Lever
2010-01-14 17:30 ` [PATCH 09/24] nfs-utils: Collect socket address helpers into one location Chuck Lever
2010-01-14 17:30 ` [PATCH 10/24] statd: Introduce statd version of matchhostname() Chuck Lever
2010-01-14 17:30 ` [PATCH 11/24] statd: add nsm_present_address() API Chuck Lever
2010-01-14 17:30 ` Chuck Lever [this message]
2010-01-14 17:30 ` [PATCH 13/24] statd: Support IPv6 is caller_is_localhost() Chuck Lever
2010-01-14 17:30 ` [PATCH 14/24] statd: Support IPv6 in sm_simu_crash_1_svc Chuck Lever
2010-01-14 17:31 ` [PATCH 15/24] sm-notify: Save mon_name and my_name strings Chuck Lever
2010-01-14 17:31 ` [PATCH 16/24] libnsm.a: Factor atomic write code out of nsm_get_state() Chuck Lever
2010-01-14 17:31 ` [PATCH 17/24] libnsm.a: Add support for multiple lines in monitor record files Chuck Lever
2010-01-14 17:31 ` [PATCH 18/24] statd: Add API to canonicalize mon_names Chuck Lever
2010-01-14 17:31 ` [PATCH 19/24] statd: Support IPv6 in sm_mon_1_svc() Chuck Lever
2010-01-14 17:31 ` [PATCH 20/24] statd: Support IPv6 in sm_stat_1_svc() Chuck Lever
2010-01-14 17:31 ` [PATCH 21/24] statd: Remove NL_ADDR() macro Chuck Lever
2010-01-14 17:32 ` [PATCH 22/24] libnsm.a: retain CAP_NET_BIND when dropping privileges Chuck Lever
2010-01-14 17:32 ` [PATCH 23/24] statd: Support TI-RPC statd listener Chuck Lever
2010-01-14 17:32 ` [PATCH 24/24] statd: update rpc.statd(8) and sm-notify(8) to reflect IPv6 support Chuck Lever
2010-01-16 13:22 ` [PATCH 00/24] Remaining IPv6 patches for statd Steve Dickson
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=20100114173036.26079.2923.stgit@localhost.localdomain \
--to=chuck.lever@oracle.com \
--cc=chris.mason@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=steved@redhat.com \
/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