Bug 195711
Summary: | signal(7) says read(2) from an inotify(7) fd is never restarted but it's wrong | ||
---|---|---|---|
Product: | Documentation | Reporter: | lilydjwg (lilydjwg) |
Component: | man-pages | Assignee: | documentation_man-pages (documentation_man-pages) |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | CC: | mtk.manpages |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | Subsystem: | ||
Regression: | No | Bisected commit-id: |
(In reply to lilydjwg from comment #0) > signal(7) says: > > > The following interfaces are never restarted after being interrupted by a > > signal handler, regardless of the use of SA_RESTART; they always fail with > > the error EINTR when interrupted by a signal handler: > > [...] > > * read(2) from an inotify(7) file descriptor. > > But it's not the case. If I use signal(2) or sigaction(2) with SA_RESTART, I > can't interrupt a read(2) for an inotify(7) fd. If I remove the SA_RESTART, > it's interrupted as expected. > > And in the kernel code fs/notify/inotify/inotify_user.c, inotify_read > returns -ERESTARTSYS when there are pending signals. Thanks for the report. It seems things changed in Linux 3.8. The man-page was correct for earlier kernel versions. I've amended the man-page text to list this case as restartable with SA_RESTART: * read(2) from an inotify(7) file descriptor (since Linux 3.8; beforehand, always failed with EINTR). I'll close this bug now. |
signal(7) says: > The following interfaces are never restarted after being interrupted by a > signal handler, regardless of the use of SA_RESTART; they always fail with > the error EINTR when interrupted by a signal handler: > [...] > * read(2) from an inotify(7) file descriptor. But it's not the case. If I use signal(2) or sigaction(2) with SA_RESTART, I can't interrupt a read(2) for an inotify(7) fd. If I remove the SA_RESTART, it's interrupted as expected. And in the kernel code fs/notify/inotify/inotify_user.c, inotify_read returns -ERESTARTSYS when there are pending signals.