linux-kernel - Re: [PATCH v3 2/3] fs: fuse: add backing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAC1kPDPZ5nw8qmvb5+b30BodNh+id=mHb8cTfJyomtL0nsVK=w@mail.gmail.com>
Date: Fri, 20 Jun 2025 14:12:04 +0800
From: Chen Linxuan <chenlinxuan@...ontech.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Christian Brauner <brauner@...nel.org>, Amir Goldstein <amir73il@...il.com>, 
	Chen Linxuan <chenlinxuan@...ontech.com>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/3] fs: fuse: add backing_files control file

On Tue, May 13, 2025 at 3:58 PM Miklos Szeredi <miklos@...redi.hu> wrote:
>
> On Tue, 13 May 2025 at 09:39, Christian Brauner <brauner@...nel.org> wrote:
>
> > No, the xattr interface is ugly as hell and I don't want it used as a
> > generic information transportation information interface. And I don't
> > want a single thing that sets a precedent in that direction.
>
> You are getting emotional and the last messages from you contain zero
> technical details.
>
> I know about the buffer sizing one, can you describe your other gripes?
>
> > > But if the data is inherently variable sized, adding specialized
> > > interface is not going to magically solve that.
> > >
> > > Instead we can concentrate on solving the buffer sizing problem
> > > generally, so that all may benefit.
> >
> > 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.
>
> > Then by all means we can come up with a scheme in procfs that displays
> > this hierarchically if we have to.
>
> Yeah, perhaps it's doable.

In my opinion, adding relevant directories and nodes under procfs does not seem
to be much different from what I did in this patch by adding nodes
under /sys/fs/fuse.
This kind of solution would still be a somewhat “non-generic” approach.
For io_uring, scm_rights, and fuse backing files,
these newly added files or directories will eventually have their own
specific names.

I’m starting to wonder: is it really meaningful to pursue “genericity”
in this context?
Especially considering that io_uring already has its own “non-generic” handling.
For introducing a new way to expose kernel-held file resources,
would the maintainers of these two features even be willing to
coordinate and make changes?

Thanks,
Chen Linxuan

>
> Thanks,
> Miklos
>
>