rpc.gssd: close upcall pipe on POLLHUP

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>