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 C7BB03858D29 for ; Mon, 15 Feb 2021 09:15:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C7BB03858D29 X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [192.168.2.103] ([84.143.151.159]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0Mfq6i-1lYjZB0iuK-00NDv5; Mon, 15 Feb 2021 10:15:25 +0100 Subject: Re: (stat(...) == -1 || faccessat(...) == -1) && errno == EINTR ?!?? To: Godmar Back Cc: William Tambe via Libc-help References: <000830b6-1cf0-6349-5667-a5af6894ac1b@web.de> From: Tobias Bading Message-ID: Date: Mon, 15 Feb 2021 10:15:24 +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:E1+MJqMl4K4kVeRCVkIvS0kPsfKNaIHNiHKjWwVQ63Djk4gPlc9 OBJO0XLb3tBbMxWEJArZjgwAjWIJqcg3sUW6Wj+Q4e6njkRgZ9R6m/zq8iRdl0DQ8qmkPho mDt++Tx4oK5m516SRO1w5HsbcwWeZjCDrqrBoG6vlI2ZuwWGxS4Xxlpst8OCgGiZ5vYDokY k6zUBFhnD3pFZc3/E1WSQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:CdYOFdV9w1A=:fD8ZnPH6e0nnCIRfwtMbFZ 6VIUnYnVjeAkwSp/tro/y0zsphYCNon5A4GK7C8Z3DJn0+MycQ3/abveG7z3+n0qGB9quq1Bh 8IxIkcLEruU8+ly3V3QkvcEO7UK+kcwhFnincvt/Eq0Cyep1PDmki7UdQ6Ay9YjfVBjLEPuHk yHpRcML5dOLqhISZvxR/Y8wZHZvc5kDC80X+R6x+/XxrJRbqSlOxmBCpoIuhNt5Qaiwpw+JBX e9+fk5aVyFs5B+hSEaAldF+6wkn2nNoWGYZFMkqTZCM/eJdWWSLUpucCa85KzvYYZRMwFS2p2 vNXyCpLJiqzHWtugDJEmqaiZSSZxoUmYpRNVnKBh8pYC2KixUWd0AU5C22SWRAtzuIe+vXA3g 7NJNdhts4fSAuVNOP0FEfs3OsYmcaQKOwrCbLEWoF3/0sQQo8r0KW49Kz0vWjPnlVlA+7VFzC nmS/1qAx0LgVp2VgWFFtYISLmFfwpr4y3IKkPHICqIx17Yh12iXb5hQ61lav11ZM+dcuetSQR 1Zp1WI0XEdKZFNF3+cI5gPiSfqh1aMi+cqzWLf2nzVuIulC8TXVhEB8zREQAzSW4VW5GTz3x+ 1WNf1+Qlm1A475DsC2WVCbx8ArZKb+XaVFKKufvJyfq7BRlUsYNPKmpl6suLQQRdkOjNQhnJc Hl3hJceATfZgjW2XtEpCKwQxTSOTLPfTwtufEgJgvpy4IYO8OC8EBV6WhE1b0+4ZCUdhMB0P8 W/JlLtwyKQ0bREbLUN+KYTc/zPIJyOMETcxHJZzT8pnDSriENAp+Fk9HciyaVodWkskWUo/ud mmvPA2noY6eCdkUjwyVoOW3CO1RzqzdQxkF8Ac6/RAh3A0EShBWcmi37qaI2LAz1rHqncACAw S6wWHn4VzFY4EqTXyO5Q== X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, PLING_QUERY, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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: Mon, 15 Feb 2021 09:15:29 -0000 > You could use systemtap to patch the kernel to see if you can trap the > path where they're returning `EINTR`. > I recently came across a blog post: > https://engineering.skroutz.gr/blog/uncovering-a-24-year-old-bug-in-the-li= nux-kernel/ > where some people did that and found a bug in the TCP code. Very > impressive. Thanks, very interesting read indeed. I haven't heard of systemtap before, sounds like a very cool tool for kernel hackers. Since I'm only doing userland stuff, I usually trust Valgrind to help me out when things get fishy. > I don't know if this qualifies as "breaking userland" [...] I'd say breaking stat() qualifies big time, but to be honest I don't really have the time/nerve to read https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html in full. The "Signal Effects on Other Functions" paragraph seems interesting, but my head explodes when I read sentences like =C2=A0 "Therefore, implementations should generally make such functions (including ones defined as extensions) interruptible." =C2=A0 "Functions not mentioned explicitly as interruptible may be so on some implementations, possibly as an extension where the function gives an [EINTR] error." English isn't my first language, so I must be reading this wrong or interpreting it in the wrong context. If a POSIX implementation was allowed to add EINTR to the list of possible error codes returned by a function defined in the standard, what kind of standard would that be? How about an implementation of malloc() which returns NULL and sets errno to EINTR when a signal is raised while the calling thread was asleep because it was waiting for a disk read from swapspace? XD Tobias =2D-- On 14.02.21 23:04, Godmar Back wrote: > I don't know if this qualifies as "breaking userland" or "this has > never worked." > > You could use systemtap to patch the kernel to see if you can trap the > path where they're returning `EINTR`. > I recently came across a blog post: > https://engineering.skroutz.gr/blog/uncovering-a-24-year-old-bug-in-the-= linux-kernel/ > where some people did that and found a bug in the TCP code. Very > impressive.