On Tue, 2009-05-05 at 08:36 +0200, Peter =C3=85strand wrote:
> On Mon, 4 May 2009, Trond Myklebust wrote:
>=20
> >> 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 NF=
S
> >> operations complete.
>=20
> I guess this means that commands cannot be terminated using Ctrl-C, s=
ince=20
> 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 ha=
ve
> >> 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().
>=20
> I see. However, it's much more common with unreachable network server=
s=20
> than unreachable local block devices.
There are plenty of networked block devices these days (iSCSI,
=46CoE, ...).