public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Tobias Bading <tbading@web.de>
To: libc-help@sourceware.org
Subject: (stat(...) == -1 || faccessat(...) == -1) && errno == EINTR ?!??
Date: Sun, 14 Feb 2021 12:13:06 +0100	[thread overview]
Message-ID: <c67bcb6b-a628-9d29-3655-3a406a52d996@web.de> (raw)

Hi.

A few days ago I encountered strange problems at home while using GNU
Emacs on GNU/Linux with Windows SMB shares in the office automounted
through the company's VPN.

Details and my current findings on the Emacs devel mailing list:
https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00835.html.

TL;DR:
Emacs' stat() and faccessat() calls sometimes return -1 and set errno to
EINTR (according to strace). Most of the time the interruption seems to
come from a SIGIO, but at least once a SIGCHLD was in the mix as well.

The behavior of returning with errno == EINTR seems to be new and/or
some kind of bug, because otherwise Emacs would handle that case with
TEMP_FAILURE_RETRY() or something to that effect, right? I've used
pretty much the same Emacs in the office (on an older GNU/Linux release)
for ages with the same Windows SMB shares and never had this problem.

The GNU/Linux man pages of stat() and faccessat() don't mention EINTR at
all, and neither does POSIX
(https://pubs.opengroup.org/onlinepubs/9699919799/).

So I guess the one million dollar question is this:
Are stat() and faccessat() permitted to return -1 with errno == EINTR,
or does that violate the POSIX (or some other) spec?

I'll probably write a small test program next to check if I can
reproduce this problem outside of Emacs, maybe with a simple SIGALRM and
an endless loop of stat()/faccessat() calls. If that reproduces the
problem it would be nice to know whether using SA_RESTART in sigaction()
has any effect.

Any ideas are very welcome... :)

Tobias

PS: I'm running Ubuntu focal (20.04.2 LTS, amd64), which currently uses
libc-bin 2.31-0ubuntu9.2, kernel linux-image-5.4.0-64-generic and
openconnect 8.05-1 to access the VPN.


             reply	other threads:[~2021-02-14 11:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-14 11:13 Tobias Bading [this message]
2021-02-14 12:18 ` Tobias Bading
2021-02-14 13:17   ` Tobias Bading
2021-02-14 15:14     ` Godmar Back
2021-02-14 15:20       ` Godmar Back
2021-02-14 17:30       ` Tobias Bading
2021-02-14 22:04         ` Godmar Back
2021-02-15  9:15           ` Tobias Bading
2021-02-15  9:24             ` Florian Weimer
2021-02-15  9:43               ` Tobias Bading
2021-02-15  9:45                 ` Florian Weimer
2021-02-15 10:02                   ` Tobias Bading
2021-02-15 10:20                     ` Florian Weimer
2021-02-15 10:36                       ` Tobias Bading
2021-02-15  8:33         ` Tobias Bading
2021-02-15  8:45           ` Konstantin Kharlamov
2021-02-15 10:25             ` Tobias Bading
2021-02-14 17:56   ` Konstantin Kharlamov
2021-02-14 18:58     ` Tobias Bading
2021-02-14 20:46       ` Konstantin Kharlamov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c67bcb6b-a628-9d29-3655-3a406a52d996@web.de \
    --to=tbading@web.de \
    --cc=libc-help@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).