On Thu, Jun 25, 2026 at 5:53 AM Matthew Wilcox <[email protected]> wrote: > > On Wed, Jun 24, 2026 at 12:06:54PM -0700, Nhat Pham wrote: > > I'm more concerned with undocumented/unexpected behavior (error type > > in this case). -EIO was an example that I saw in ovl_real_file() > > itself, but I'm not familiar enough with overlayfs to know if that's > > the extent of it. > > > > But I'm OK with just updating the documentation with a simple note > > that other error maybe propagated from the underlying fs, if no one > > else thinks it's a problem :) > > That's ALWAYS true. POSIX even says so explicitly in section 2.3: > > Implementations may support additional errors not included in this list, > may generate errors included in this list under circumstances other > than those described here, or may contain extensions or limitations > that prevent some errors from occurring. > > We don't generally bother to document that pretty much every syscall may > return -ENOMEM if it can't allocate memory. That's just ... expected. > open(2) documents the possibility, but read(2) doesn't. I think it's > the same for EIO. Any operation which accesses storage can return -EIO.
Ah I see! Admittedly, I'm not aware with this POSIX detail. Thanks for the clarifications and pointers, Matthew! In that case, I have no further comments on this patch, and defer to overlayfs and fs folks for FS-specific correctness. Reviewed-by: Nhat Pham <[email protected]>
