On 03/15/2010 01:51 PM, Chuck Lever wrote:
> During any file locking interaction between an NFS client and server,
> the client tells the server what hostname it will use as the mon_name
> argument of the SM_NOTIFY request sent by the client when it reboots.
> This is the "caller_name" argument of an NLMPROC_LOCK request.
>
> The server, however, never tells the client what mon_name argument
> it will use when sending an SM_NOTIFY request. In order to recognize
> the server, clients usually guess what mon_name the server might
> send, by using the server hostname provided by the user on the mount
> command line.
>
> Frequently, the user provides an unqualified server name on the mount
> command. The server might then call the client back with a fully
> qualified domain name, which might not match in some cases.
>
> Solaris, and perhaps other implementations, attempt to mitigate this
> problem by sending two SM_NOTIFY requests to each peer: one with an
> unqualified mon_name argument, and one with a fully qualified mon_name.
>
> Implement such a scheme for sm-notify.
>
> Since my_name is almost always the fully-qualified hostname associated
> with the local system, just wiping the left-most '.' in the my_name
> argument and sending another SM_NOTIFY is nearly always sufficient.
>
> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
> ---
>
> utils/statd/sm-notify.c | 21 +++++++++++++++++----
> 1 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/utils/statd/sm-notify.c b/utils/statd/sm-notify.c
> index 2d14668..437e37a 100644
> --- a/utils/statd/sm-notify.c
> +++ b/utils/statd/sm-notify.c
> @@ -634,15 +634,28 @@ recv_rpcbind_reply(struct sockaddr *sap, struct nsm_host *host, XDR *xdr)
> }
>
> /*
> - * Successful NOTIFY call. Server returns void, so nothing
> - * we need to do here.
> + * Successful NOTIFY call. Server returns void.
> + *
> + * Try sending another SM_NOTIFY with an unqualified "my_name"
> + * argument. Reuse the port number. If "my_name" is already
> + * unqualified, we're done.
> */
> static void
> recv_notify_reply(struct nsm_host *host)
> {
> - xlog(D_GENERAL, "Host %s notified successfully", host->name);
> + char *dot = strchr(host->my_name, '.');
>
> - smn_forget_host(host);
> + if (dot != NULL) {
> + *dot = '\0';
> + host->send_next = time(NULL);
> + host->xid = 0;
> + if (host->timeout >= NSM_MAX_TIMEOUT / 4)
> + host->timeout = NSM_MAX_TIMEOUT / 4;
> + insert_host(host);
What happens when host->my_name now resolves to host in a
different domain? Will this mean we now will be sending SM_NOTIFYs
to random hosts?
Also, what happens when host->my_name does not resolve to anything?
Looking at notify(), it appears the unqualified my_name will stay
on the hosts list, because notify_host() will fail since the
smn_lookup() fails and will always set host->ai = NULL. Unless
I am missing something, this will cause notify() to increment
hp->retries and insert the hp pointer back on the host list.
I don't see how that cycle will broken....
steved.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
