On Thu, Jul 31, 2025 at 11:45:37AM +0200, Christian Brauner wrote: > > > (That said, my opinion is that after years of all of us telling > > > programmers that fsync is the golden standard for checking if bad stuff > > > happened, we really ought only be clearing error state during fsync.) > > > > > > > That is pretty doable. The only question is whether it's something we > > *want* to do. Something like this would probably be enough if so: > > > > diff --git a/fs/open.c b/fs/open.c > > index 7828234a7caa..a20657a85ee1 100644 > > --- a/fs/open.c > > +++ b/fs/open.c > > @@ -1582,6 +1582,10 @@ SYSCALL_DEFINE1(close, unsigned int, fd) > > > > retval = filp_flush(file, current->files); > > > > + /* Do an opportunistic writeback error check before returning. */ > > + if (likely(retval == 0)) > > + retval = filemap_check_wb_err(file_inode(file)->i_mapping, file->f_wb_err); > > I think that's a bad idea. 90% of the code will not check close for > any errors so they'll never see any of this anyway. 1% will be the very > interested users that may care about. 9% will be tests that suddenly > start failing because they assert on close(fd) I'm pretty sure. > > So I don't think this provides a lot of value. At least I can't see it yet. Yeah, I think changed my mind to thinking it's sensible to say that if @fd was removed from the file descriptor table then close() returns 0 no matter what else happened to the file. --D
