summaryrefslogtreecommitdiffstats
path: root/support/nfs/cacheio.c
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2010-03-17 06:15:08 -0400
committerSteve Dickson <steved@redhat.com>2010-03-17 06:15:08 -0400
commit900df0e7c0b9006d72d8459b30dc2cd69ce495a5 (patch)
treeea8d4ef6424853844a1b5931aea20d3cabb8235b /support/nfs/cacheio.c
parent70c59e231e7257ac93b68ba4b844f8d10a6af4a8 (diff)
downloadnfs-utils-900df0e7c0b9006d72d8459b30dc2cd69ce495a5.tar.gz
nfs-utils-900df0e7c0b9006d72d8459b30dc2cd69ce495a5.tar.xz
nfs-utils-900df0e7c0b9006d72d8459b30dc2cd69ce495a5.zip
sm-notify: Use my_name when sending SM_NOTIFY requests
The mon_name argument of an SM_NOTIFY request is a string that identifies the rebooting host. sm-notify should send the my_name provided by the local lockd at the time the remote was monitored, rather than cocking up a mon_name argument based on the present return value of gethostname(3). If the local system's hostname happened to change after the last reboot, then the string returned by gethostname(3) will not be recognized by the remote. Thus the remote will never initiate lock recovery for the original named host, possibly leaving stale locks. The existing behavior of using the -v command line option as the mon_name argument is preserved, but we now prevent sending an IP presentation address, as some non-Linux implementations don't recognize addresses as valid mon_names. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Diffstat (limited to 'support/nfs/cacheio.c')
0 files changed, 0 insertions, 0 deletions