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@xxxxxxxxxxxxxxxxxxxx Reporter: sgunderson@xxxxxxxxxxx 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
