Re: close() can be interrupted with undefined behavior
Lassi Kortela 21 Jul 2019 12:11 UTC
Thanks for the LWN link. That site is always informative.
Even the verbose solution pasted into my last mail is subtly wrong. From
the blog comments:
"So, the problem is that close() can actually return interesting return
values other than 0. AFS, for instance, doesn't write to your networked
file until you close it, so your quota might have been filled
meanwhile... so it can return ENOSPC, and not checking for ENOSPC on
close() can cause data loss. You actually want to see this error, which
is why "if the close returned EINTR, assume it was okay if the fd no
longer exists" doesn't work."
It would appear that there's no way to write reliable userland programs
if the kernel can interrupt close(). And there is so much code that just
does close() without even checking its return value. I've rarely checked
it myself. That LWN article has a telling quote: "At one time many years
ago there was a path in the kernel that returned an error from close and
it broke so many things. Even emacs crashed."