From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.web.de (mout.web.de [217.72.192.78]) by sourceware.org (Postfix) with ESMTPS id 844463858024 for ; Sun, 14 Feb 2021 11:13:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 844463858024 X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [192.168.2.103] ([84.143.151.159]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LwqFo-1lvi262NmC-016PVi for ; Sun, 14 Feb 2021 12:13:06 +0100 To: libc-help@sourceware.org From: Tobias Bading Subject: (stat(...) == -1 || faccessat(...) == -1) && errno == EINTR ?!?? Message-ID: Date: Sun, 14 Feb 2021 12:13:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Provags-ID: V03:K1:xVLKelkWMVmNn4OXWGqeCLtBncM4Mvk1wDjZ01nxxusSTZbA5VL lVDpuqIoOqDDBpdq8pIJFkIRf69+Qx8UM98r8Hjt65S3ZTHsEtWSkzql9woAMhMUaF+vtvl EHTyLn7MQHU9WuGVGbC62EIzUbwcSovV9rT74ewuNbrdGuAE7U9TOI6Qoa7Z3LnCmFBKuLw Gjj61CXCnumHFLjy/33Ew== X-UI-Out-Filterresults: notjunk:1;V03:K0:EeCCibxsivg=:/YONCINCBsovK4gajw5a5H 3RF6K55q+3qQVJ4Yu3C9KF1mI9tEMdPswnX2Z0cxT7ux7XG4pmiUVPTH81mreZOVxzkbMQles +UCKhYi+R/I7JjEa33dS94/nG/2ujR3+hDU3gm23fqkjchrFaunZHaoNK7zbxF8H/Ws8Vuduo zYTLwV4ldv159eiS+Xz2znumsQV4jo35Q1Vr8RYVfRC1CHXNNqGicPYmJM1D1z8FspP9XOEQv ZGKI+X2nsK1QYvTke/8AhsLOZ1CcHw3QHhqzo2VMDMjUs0NLk2xWo33iM3b+A6b9H+LbLBJrp QUj0oKMmWaBiJsDaxDFVakHfqRQypVBEeAGYT1OTJuFEWyhJRrmN4MrjwNf9vOu4YLJGIcaWu fcswe7JZ7NY8e9Lxj108NagFCheTH6yYAv/DdJsTYyrMcvaGSAHcNMVyglcFap4w5xBIqRGsP dzwiKQiPA6zx23C85OdbyUm6qXGIMe04Q9O/yZwBNlDZHjgtVfecLr3Dlq7h403e035pRfn5N Upv1vZkG6y1zSXHm5zY2JoHsRsF+++8fPAgmTdgpU5TiZahIvgrebcVGG8AYAwB5vThzIsLSs T3iYa9QSNIqqK/lmG7BvbZucBW+f6X9/QpkfmlMvzw/5vYDXtohoBwO69kNlwQQao7oKXXyLZ Ml16sNqJdW3vT/oSdDH9bcsrgtHq1TB0WbbD+fSYWqquA0QBrsivcUjBP9CG7DCZL/FKHsq0t OddXLdo4kq5EUjPupm0bnOD6Dn8HweSjdUP+mbTj0a3kSwamn4r91r9PvTDIfe3jR/xiwApYB tlfR61XoNnXQKCGw4puhcS4yURBSVVcovg0MohMfoAHPipBXOB2lJ+OKtL/n4vTCKTfTj4pxv i5xT+LcCqX+Uk5bWaYbA== X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, LOTS_OF_MONEY, MONEY_NOHTML, PLING_QUERY, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 11:13:12 -0000 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 =3D=3D 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 =3D=3D 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.