Re: [PATCH v3 2/3] fs: fuse: add backing_files control file

[Miklos Szeredi <miklos@szeredi.hu>]

On Tue, 13 May 2025 at 09:57, Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Tue, 13 May 2025 at 09:39, Christian Brauner <brauner@kernel.org> wrote:

> > The xattr system call as far as I'm concerned is not going to be pimped
> > to support stuff like that.
>
> Heh?  IIRC there were positive reactions to e.g. "O_XATTR", it just
> didn't get implemented.  Can try to dig this up from the archives.

Here it is:

https://lore.kernel.org/all/CAHk-=wjzLmMRf=QG-n+1HnxWCx4KTQn9+OhVvUSJ=ZCQd6Y1WA@mail.gmail.com/

Quoting Linus inline:

| IOW, if you do something more along the lines of
|
|        fd = open(""foo/bar", O_PATH);
|        metadatafd = openat(fd, "metadataname", O_ALT);
|
| it might be workable.
|
| So you couldn't do it with _one_ pathname, because that is always
| fundamentally going to hit pathname lookup rules.
|
| But if you start a new path lookup with new rules, that's fine.
|
| This is what I think xattrs should always have done, because they are
| broken garbage.
|
| In fact, if we do it right, I think we could have "getxattr()" be 100%
| equivalent to (modulo all the error handling that this doesn't do, of
| course):
|
|   ssize_t getxattr(const char *path, const char *name,
|                         void *value, size_t size)
|   {
|      int fd, attrfd;
|
|      fd = open(path, O_PATH);
|      attrfd = openat(fd, name, O_ALT);
|      close(fd);
|      read(attrfd, value, size);
|      close(attrfd);
|   }
|
| and you'd still use getxattr() and friends as a shorthand (and for
| POSIX compatibility), but internally in the kernel we'd have a
| interface around that "xattrs are just file handles" model.
|
|                Linus