I saw a recent bug report that showed when a process set up a dnotify against
the autofs root and then attempted an access(2) call inside the autofs
namespace on a mount that would fail, it would create a signal/restart loop.

The cause is that the autofs code checks to see if any signals are pending
after it waits on a response from the autofs daemon.  If it finds any, it
assumes that autofs_wait was interrupted, and that it should return
-ERESTARTNOINTR.  The problem with this is that a signal_pending(current)
check will return true if *any* signals were received, not just if a signal
that interrupted the wait was received.  autofs_wait explicitly blocks all
signals except for SIGKILL, SIGQUIT, and SIGINT before calling
interruptible_sleep_on.

The effect is that if a dnotify is set against the autofs root, when the
autofs daemon creates the directory, a dnotify event will be sent to the
originating process.  Since the code in autofs_root_lookup doesn't check to
see what signals are actually pending, it bails early, telling the caller to
try again.  The loop goes on forever until interrupted via one of the actual
interrupting signals.

The following patch makes both autofs_root_lookup and autofs4_root_lookup
verify that one of its defined "shutdown" signals are pending before bailing
out early.  Any other signal should be delivered later, as expected.  It
doesn't matter if the signal occured outside of the sleep in autofs_wait.  The
calling process will either go away or try again.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>