On Tue, 2009-05-05 at 08:36 +0200, Peter Åstrand wrote: > On Mon, 4 May 2009, Trond Myklebust wrote: > > >> Since 2.6.25, the behavior of the NFS client has been a mix of the > >> two. I believe the current behavior is that SIGKILL can terminate an > >> NFS operation, but all other signals are deferred until pending NFS > >> operations complete. > > I guess this means that commands cannot be terminated using Ctrl-C, since > that generates a SIGINT? If so, this is a change for the worse. The *_killable() behaviour is to exit on all fatal signals. The definition of a fatal signal is any signals that is not blocked, that does not have a handler, and that is not listed in the SIG_KERNEL_IGNORE_MASK or SIG_KERNEL_STOP_MASK (see the definition of sig_fatal() in include/linux/signal.h) and that won't result in a core dump (see the definition of complete_signal() in kernel/signal.c). An unhandled and unblocked SIGINT should therefore result in the sleep being interrupted. > >> The mount command continues to accept both options, but neither have > >> any effect on the client's behavior (both options are no-ops). > > > > Note that this behaviour is true of local filesystems too, since > > generic_file_read() has been changed to call lock_page_killable() > > instead of the uninterruptible lock_page(). > > I see. However, it's much more common with unreachable network servers > than unreachable local block devices. There are plenty of networked block devices these days (iSCSI, FCoE, ...). -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
