• Andrew Morton's avatar
    [PATCH] autofs4: dnotify + autofs may create signal/restart syscall loop · 44367d15
    Andrew Morton authored
    From: Ian Kent <raven@themaw.net>
    
    From: Jeff Mahoney <jeffm@suse.com>
    
    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.
    44367d15
root.c 15.5 KB