rpc.gssd: close upcall pipe on POLLHUP
authorChuck Lever <chuck.lever@oracle.com>
Thu, 19 Jul 2012 13:40:30 +0000 (09:40 -0400)
committerSteve Dickson <steved@redhat.com>
Thu, 19 Jul 2012 13:40:30 +0000 (09:40 -0400)
commit4dac21d1e8ff31c3b01f7f29e7cf877e89f09eaa
tree91d45676610db3e8f23db61eca8fad50e924f1b7
parent76908c3f14a12e865054ea5d6e4cad201c28839a
rpc.gssd: close upcall pipe on POLLHUP

When a POLLHUP event is received on a pipe file descriptor, that
means the other side has closed its end of the pipe.  If the
receiver does not close its end of the pipe, the pipe is left in an
open-but-unlinked state.

For a "gssd" upcall pipe, the kernel may close its end, removing the
directory entry for it, and then later create a fresh pipe named
"gssd" in the same directory.  In this case, rpc.gssd continues to
listen on the open-but-unlinked previous "gssd" pipe.  Thus upcalls
on the new "gssd" pipe are left unanswered.

In addition, poll(2) continues to return POLLHUP on the old pipe.
Since there is no logic to close the pipe in rpc.gssd, poll(2) always
returns immediately, and rpc.gssd goes into a tight loop.

Typically, the kernel closes upcall pipes and destroys their
parent directory at the same time.  When an RPC client's directory
vanishes, rpc.gssd sees the change via dnotify and eventually
invokes destroy_client() which closes the user-space end of the
pipes.

However, if the kernel wants to switch authentication flavors (say
from AUTH_KRB5 to AUTH_UNIX) on an RPC client without destroying it,
the upcall pipes go away, but the RPC client's directory remains.
rpc.gssd invokes update_client_list(), but that logic never closes
upcall pipes if the client directory is still in place.

After a POLLHUP on a pipe, close it when rpc.gssd reconstructs its
list of upcall clients.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
utils/gssd/gssd.h
utils/gssd/gssd_main_loop.c
utils/gssd/gssd_proc.c