[Bug 97721] New: signal(7) is unclear on EINTR behavior against disks

[Bug 97721] New: signal(7) is unclear on EINTR behavior against disks

[bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r]

https://bugzilla.kernel.org/show_bug.cgi?id=97721

            Bug ID: 97721
           Summary: signal(7) is unclear on EINTR behavior against disks
           Product: Documentation
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P1
         Component: man-pages
          Assignee: documentation_man-pages-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
          Reporter: sgunderson-jG/AHqQBv7lBDgjK7y7TUQ@public.gmane.org
        Regression: No

Hi,

This came up in a discussion recently; signal(7) says:

       If a blocked call to one of the following interfaces is interrupted
       by a signal handler, then the call will be automatically restarted
       after the signal handler returns if the SA_RESTART flag was used;
       otherwise the call will fail with the error EINTR:

           * read(2), readv(2), write(2), writev(2), and ioctl(2) calls on
             "slow" devices.  A "slow" device is one where the I/O call may
             block for an indefinite time, for example, a terminal, pipe, or
             socket.  (A disk is not a slow device according to this
             definition.)  If an I/O call on a slow device has already
             transferred some data by the time it is interrupted by a signal
             handler, then the call will return a success status (normally,
             the number of bytes transferred).

In other words, for "slow" devices, it's defined that you get restart or EINTR
depending on SA_RESTART setting; that's fine. However, while it seems the
_intention_ of the last paragraph is to say that "fast" devices never can get
EINTR (always restart), it is possible to read it leaving the behavior of fast
devices entirely up to the reader's imagination (ie., the paragraph simply says
nothing about that). The practical behavior, to the best of my knowledge, is
that these calls against filesystems on disks always restart (never EINTR). I
believe this should be written out more explicitly in this section.

A different question is what counts as “fast” or “slow” in edge cases. In
particular, NFS coutns as a “fast” device when mounted with the “hard” option
(the default), but not with the “soft” or “intr” options. This is documented in
nfs(5), but could maybe do with a reference. Then there's FUSE filesystems,
which seemingly always count as “slow”; even simple operations can return
EINTR. I don't know if this is a bug or intentional, so one should probably
exercise caution before documenting it.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 97721] signal(7) is unclear on EINTR behavior against disks

[bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r]

https://bugzilla.kernel.org/show_bug.cgi?id=97721

Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
         Resolution|---                         |CODE_FIX

--- Comment #1 from Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ---
I've amended the mention of sick devices to instead say


    Note that a (local) disk is not a slow device according to 
    this definition; I/O operations on disk devices are not 
    interrupted by signals.

Beyond the hint "(local)", I'm reluctant to say anything about NFS, and I don't
know what the FUSE details are, so I'll close this bug now. Please reopen, if
you think more is required.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 97721] signal(7) is unclear on EINTR behavior against disks

[bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r]

https://bugzilla.kernel.org/show_bug.cgi?id=97721

--- Comment #2 from Steinar H. Gunderson <sgunderson-jG/AHqQBv7lBDgjK7y7TUQ@public.gmane.org> ---
Thanks! This makes it much clearer.

In a sense, it's sad that FUSE is the way it is, but I think that's maybe more
of a FUSE bug than a documentation bug.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 97721] signal(7) is unclear on EINTR behavior against disks

[bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r]

https://bugzilla.kernel.org/show_bug.cgi?id=97721

Michael Wright <mdwrigh2-e4nNhFGpWWo@public.gmane.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mdwrigh2-e4nNhFGpWWo@public.gmane.org

--- Comment #3 from Michael Wright <mdwrigh2-e4nNhFGpWWo@public.gmane.org> ---
Note that a btrfs formatted drive can also return EINTR during an ioctl
(https://github.com/torvalds/linux/blob/master/fs/btrfs/ioctl.c#L825) and FUSE
explicitly documents this behavior
(https://github.com/torvalds/linux/blob/master/Documentation/filesystems/fuse.txt#L169).
Is there documentation somewhere about this restriction?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html