Hi, On Sat, May 17, 2025 at 07:46:48AM +0200, Alejandro Colomar wrote: > Hi Ted, Rich, > > On Fri, May 16, 2025 at 09:05:47AM -0400, Rich Felker wrote: > > 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. BTW, I don't think that's a correct interpretation. The manual page clearly says after close(2), even on error, the fd is closed and not usable. The issue I see is a program thinking it failed and trying to copy the file again or reporting an error. On the other hand, as Vincent said, maybe this is not so bad. For certain files, fsync(2) is only described for storage devices, so in some cases there's no clear way to make sure close(2) won't fail after EINTR (maybe calling sync(2)?). So, maybe considering it an error wouldn't be a terrible idea. I don't know. Cheers, Alex > > Hmmm, this page will need a kernel/libc differences section where I > should explain this. > > On Fri, May 16, 2025 at 10:20:24AM -0400, Theodore Ts'o wrote: > > On Fri, May 16, 2025 at 09:05:47AM -0400, Rich Felker wrote: > > > > > 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". > > > > If glibc maintainers want to deal with breaking userspace, then as a > > kernel developer, I'm happy to let them deal with the > > angry/disappointed users and application programmers. :-) > > Which breakage do you expect from the behavior that musl has chosen? > > I agree that the POSIX invention of EINPROGRESS is something that would > break users. However, in removing the error completely and making it a > success, I don't see the same problem. That is, if a program calls > close(2) and sees a return of 0, or sees a return of -1 with EINTR on > Linux, both mean "the file descriptor has been closed, and the contents > of the file will *eventually* reach the file". > > In which cases do you expect any existing Linux program to behave > differently on 0 and on EINTR? > > > Have a lovely day! > Alex > > -- > <https://www.alejandro-colomar.es/> -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
