On Thu, 1 Oct 2026 at 18:39, Amir Goldstein <[email protected]> wrote:
>
> On Thu, Oct 1, 2026 at 5:09 PM Miklos Szeredi <[email protected]> wrote:
> > @@ -118,11 +111,9 @@ static int fuse_file_uncached_io_open(struct inode
> > *inode,
> > struct fuse_backing *fb)
> > {
> > struct fuse_inode *fi = get_fuse_inode(inode);
> > - int err;
> >
> > - err = fuse_inode_uncached_io_start(fi, fb);
> > - if (err)
> > - return err;
> > + if (!fuse_inode_uncached_io_start(fi, fb))
> > + return fuse_EIO("failed to start uncached I/O");
>
> Why lose the internal error code?
> If server implementation is wrong that is a good hint of what went wrong.
> ETXTBSY is trying to mix cache mode and passthrough mode.
> EBUSY is trying to passthrough to two different backing inodes.
I'll move the error codes back, and turn them into fuse_EIO with an
appropriate message in the caller.
> > @@ -234,22 +228,10 @@ int fuse_file_io_open(struct file *file, struct inode
> > *inode)
> >
> > if (ff->open_flags & FOPEN_PASSTHROUGH)
> > err = fuse_file_passthrough_open(inode, file);
> > - else
> > - err = fuse_file_cached_io_open(inode, ff);
> > - if (err)
> > - goto fail;
> > + else if (!fuse_file_cached_io_open(inode, ff))
> > + err = fuse_EIO("conflicting passthrough open");
>
> Same here.
> If we can keep this bit of information and print it - it is helpful IMO,
> even if we don't go all the way to annotate every error case with
> a pretty log.
There is just one way to fail fuse_file_cached_io_open() so I think
this is okay.
Thanks,
Miklos
