SM_STAT is usually not used by most contemporary NSM implementations,
but for consistency, it gets the same treatment as sm_mon_1_svc(),
since both should use the same logic to determine whether a mon_name
is able to be monitored.
Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
---
utils/statd/stat.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/utils/statd/stat.c b/utils/statd/stat.c
index 477f632..14caa16 100644
--- a/utils/statd/stat.c
+++ b/utils/statd/stat.c
@@ -38,19 +38,21 @@
* 3/ That's what we always did in the past.
*/
struct sm_stat_res *
-sm_stat_1_svc (struct sm_name *argp, struct svc_req *rqstp)
+sm_stat_1_svc(struct sm_name *argp, __attribute__((unused)) struct svc_req *rqstp)
{
static sm_stat_res result;
+ struct addrinfo *ai;
xlog(D_CALL, "Received SM_STAT from %s", argp->mon_name);
- if (gethostbyname (argp->mon_name) == NULL) {
- xlog_warn ("gethostbyname error for %s", argp->mon_name);
+ ai = nsm_forward_lookup(argp->mon_name);
+ if (ai == NULL) {
result.res_stat = STAT_FAIL;
xlog (D_GENERAL, "STAT_FAIL for %s", argp->mon_name);
} else {
result.res_stat = STAT_SUCC;
xlog (D_GENERAL, "STAT_SUCC for %s", argp->mon_name);
+ freeaddrinfo(ai);
}
result.state = MY_STATE;
return(&result);
--
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
