On Fri, May 16, 2025 at 02:52:05PM +0200, Alejandro Colomar wrote: > POSIX.1-2024 now mandates a behavior different from what Linux (and many > other implementations) does. It requires that we report EINPROGRESS for > what now is EINTR. > > There are no plans to conform to POSIX.1-2024 within the Linux kernel, > so document this divergence. Keep POSIX.1-2008 as the standard to > which we conform in STANDARDS. > > Link: <https://sourceware.org/bugzilla/show_bug.cgi?id=14627> > Link: <https://pubs.opengroup.org/onlinepubs/9799919799/functions/close.html> > Cc: Jan Kara <jack@xxxxxxx> > Cc: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx> > Cc: Christian Brauner <brauner@xxxxxxxxxx> > Cc: Rich Felker <dalias@xxxxxxxx> > Cc: <linux-fsdevel@xxxxxxxxxxxxxxx> > Cc: <linux-api@xxxxxxxxxxxxxxx> > Cc: <libc-alpha@xxxxxxxxxxxxxx> > Signed-off-by: Alejandro Colomar <alx@xxxxxxxxxx> > --- > > Hi, > > I've prepared this draft for discussion. While doing so, I've noticed > the glibc bug ticket, which sounds possibly reasonable: returning 0 > instead of reporting an error on EINTR. That would be an option that > would make us conforming to POSIX.1-2024. And given that a user can > (and must) do nothing after seeing EINTR, returning 0 wouldn't change > things. > > So, I'll leave this patch open for discussion. FWIW musl adopted the EINPROGRESS as soon as we were made aware of the issue, and later changed it to returning 0 since applications (particularly, any written prior to this interpretation) are prone to interpret EINPROGRESS as an error condition rather than success and possibly misinterpret it as meaning the fd is still open and valid to pass to close again. In general, raw kernel interfaces do not conform to any version of POSIX; they're just a low-impedance-mismatch set of inferfaces that facilitate implementing POSIX at the userspace libc layer. So I don't think this should be documented as "Linux doesn't conform" but (hopefully, once glibc fixes this) "old versions of glibc did not conform". Rich
