Bug 97721
| Summary: | signal(7) is unclear on EINTR behavior against disks | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | Steinar H. Gunderson (steinar+kernel) |
| Component: | man-pages | Assignee: | documentation_man-pages (documentation_man-pages) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | mdwrigh2, mtk.manpages |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | No | Bisected commit-id: | |
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.
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. 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? |
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.