From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.web.de (mout.web.de [212.227.17.12]) by sourceware.org (Postfix) with ESMTPS id 99CBA3857C61 for ; Sun, 14 Feb 2021 17:30:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 99CBA3857C61 X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [192.168.2.103] ([84.143.151.159]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MECCd-1l3Oko0vsj-00AILU; Sun, 14 Feb 2021 18:30:51 +0100 Subject: Re: (stat(...) == -1 || faccessat(...) == -1) && errno == EINTR ?!?? To: Godmar Back Cc: libc-help@sourceware.org References: <000830b6-1cf0-6349-5667-a5af6894ac1b@web.de> From: Tobias Bading Message-ID: Date: Sun, 14 Feb 2021 18:30:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Provags-ID: V03:K1:unRZ+E6uOGawlj5yoBJ7U3j7gkziaMkVpDN9T0+TBcs0U1bhpm7 n7D3OfiF0xpn8FlEURspPwK39pxPmCv6Ik3QroKvgHHEIXX98U/kp0bgtch5Mexhz1MRrM/ V+uFBo4gnCLlAnKvRqD9bRepZrNUSAeLoaMBG/Ii8EnUfp5DNU3AJQ7ts3QLOQQ3eBnR+1w VL+Nv/L7MylFaOPbstoUw== X-UI-Out-Filterresults: notjunk:1;V03:K0:fk5ogpjC2GE=:8reS/vsBSjhMEnY3jWGs3K cHHV4W0EwrOKZLS0WB0NApdeokV1JtAG90JYxklG3KESqi1BjdS1IEPFJehVLzZbxWqkH/XXR K/b8cY+T29CL8pDvB3fSHxUAxDjOKGk+3deFlqkKDIJCb5B55KZvFrAXYpPCKm37zurhTR3Ai rja4A7Io6jrRowrj2AQTW5slRqwGXNLPVempl9+lYqN/+x8eWQcXWKx/TPEI2UanL1LqB7VBq wvgkec9sA844eW5cLorKXlcSq0Y7ME08wMoktw4Tbp17o6cSpSSLjWKE/GRZ3QGOvQ90cZSoA 9pFz7FwkkEHlqsl+HCed/z3V7hfqbu7k4BBYYfgUUBJcm1qcEKp2diLMcqvtUm5pzeaeL3g+W KbtoQH84p10xg0kNlsBcNS1paACMy9kTEW8tZN+cFKBx0FutKBC1ItWQhVm5vVDePWHjzZ1EO VJLIVDnVwF8Y4xls5wgHuqJtGVYBqqj1bXLnC2oTrumeNMo+1GiY+CRX2aMRGg70I+SCJ3Hu3 kucuo29jOPeWjF0+te/OYae4AVbOT6WhLMP663qNkWti2x8kDN6MUNoLYaF5yP6RHqmwDLy4j TaBs+8CNOYn4qL/Shv6Whf7ivSOj5PJr86qzG2QiyKREj5VkR8dq1zns45Bm5A/brZ0RSjo8r d1BeG9zT7zNtVxLnaNGT/ff+NQzWESApZCWtp+AUOcAuVP+en3JQIJfJTiHCEjny8+d1hZUxn kIUGq0nVkvJuQytOq5sh/Ss65BjrqDHgrzyNdPdabBnRBNrthOrWUC1KECyx+JV0s+SPmBUwf ovKs3CannO2x9AvSvO6iVEKv1ZipAJ/6FZQ4z5Hv2a3VjzomPyaouB9sF7iWO6BX8DTXPaRan BItfMz79Gr6YMRjo5P9w== X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, PLING_QUERY, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 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 17:31:00 -0000 Hi Godmar, thanks a lot for your feedback. > Bringing up POSIX may not be the most fruitful course of action, and > asking for compensation in the C library (as in doing an automatic > restart in the C library system call wrapper) is generally not a good > idea to my knowledge. Sorry if my mail sounded like I was trying to point fingers or anything. I simply chose the GNU libc mailing list because I couldn't find the definitive answer to the seemingly innocent question "Can stat() or faccessat() return -1 with errno =3D=3D EINTR?", neither in their man page= s, some standard spec like POSIX, nor the depth of the internet. I've been writing software for different UNIXes for a few decades now and so far I primarily followed the(/my own?) rule "if a man page doesn't mention EINTR, you don't need to worry about it". If that rule is incorrect, I have quite a few lines of code to review and wouldn't even know where to start. XD EINTR is definitely a very special errno that needs to be handled in userland, *if* a function is known to return with errno EINTR in (more or less) specific cases. But there's a ton of ancient userland code that calls stat() without handling EINTR, probably because the function never returned EINTR before and no documentation ever claimed that it could. If that function is able to return with EINTR now, it has the potential to break a lot of existing code. > Your choices are, in my opinion: > - to handle `EINTR` in user mode Yes, wrapping TEMP_FAILURE_RETRY() macros around the stat() and faccessat() calls in Emacs' source code did work as a band-aid. > - to file a bug (and propose a fix) against the kernel. If the GNU libc devs agree that neither stat() nor faccessat() should ever return with errno EINTR and this error code is coming directly from a syscall, then that's the way to go I guess. > Specifically, inside the kernel, most system calls are restartable > (and should be restarted if `SA_RESTART` is given), but occasionally > you find a place where the kernel implementor decided that they can't > restart the system call, in which case `EINTR` is propagated to user > land.=C2=A0 I've encountered this personally in the past with > `tcsetattr()`. > Also, a link to when I brought up a similar issue in 2011 about tcsetattr(): > http://lkml.iu.edu/hypermail/linux/kernel/1110.1/02954.html A kernel implementor decides to let EINTR propagate into userland? o.O In case of tcsetattr() or stat(), wouldn't that be in clear violation of Linus' "WE DO NOT BREAK USERSPACE!" first rule of kernel maintenance? (https://lkml.org/lkml/2012/12/23/75) What happened in the tcsetattr() case? The man page of tcsetattr() doesn't mention EINTR, did they revert the kernel change? > You'd need to > look in https://github.com/torvalds/linux/tree/master/fs/cifs for > places where they set something to `-EINTR` and then fail to turn it > into `-ERESTARTSYS` and do not have good reason to do so. Thanks for the pointers. Do you know whether -ERESTARTSYS is used to request an unconditional restart of the system call, or is SA_RESTART specified (or not) in userland also a factor? If we agree that stat() should never return with EINTR, than SA_RESTART shouldn't be a factor. (BTW, Emacs is intentionally not using SA_RESTART in emacs_sigaction_flags() in src/sysdep.c.) > PS: This discussion may be helpful > https://www.spinics.net/lists/stable/msg440182.html - maybe it's your > bug? Thanks!!! I'm running a 5.4 kernel, but since that mail is barely a month old I have to check whether my current kernel contains that patch. Tobias