| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Statd is not unlinking host files during SM_UNMON and
SM_UNMON_ALL calls because the given host is still on the run-time
notify list (rtnl) and the check flag is set when xunlink() is
called. But the next thing the caller of xunlink() does is
remove the host from the rtnl list which means the
unlink will never happen.
So this patch removes the check flag from xunlink() since
its not needed and correctly allocates and frees memory
used by xunlink().
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Linux kernel's lockd requires that rpc.statd perform notification
callbacks from a privileged source port. To guarantee rpc.statd gets a
privileged source port but runs unprivileged, it calls
statd_get_socket() then drops root privileges before starting it's svc
request processing loop.
Statd's svc request loop is the only caller of the process_foo()
functions in utils/statd/rmtcall.c, but one of them,
process_notify_list() attempts to invoke statd_get_socket() again.
In today's code, this is unneeded because statd_get_socket() is always
invoked before my_svc_run(). However, if it ever succeeded, it would
get an unprivileged source port anyway, causing the kernel to reject
all subsequent requests from statd.
Thus the process_notify_list() function should not ever call
statd_get_socket() because root privileges have been dropped by this
point, and statd_get_socket() wouldn't get a privileged source port,
causing the kernel to reject all subsequent SM_NOTIFY requests.
So all of the process_foo functions in utils/statd/rmtcall.c should use
the global sockfd instead of a local copy, as it already has a
privileged source port.
I've seen some unexplained behavior where statd starts making calls to
the kernel via an unprivileged port. This could be one way that might
occur.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If statd dies and is restarted, it forgets what peers the kernel
is interested in monitoring, and so will not forward NOTIFY
requests properly.
With this patch the required information is recorded in the files
in /var/lib/nfs/sm/* so that a kill/restart does what you might
hope.
Signed-off-by: Neil Brown <neilb@suse.de>
|
| |
|
|
|
| |
With -L (for Listen-only) or --no-notify, statd will not run
sm-notify.
|
| |
|
|
|
| |
statd now execs sm-notify to notify peers and only listens to
monitor requests and remote notifications itself.
|
| |
|
|
| |
unused labels, constness, signedness.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
