Please review this patch series carefully. I am new to kernel
development and I am not quite sure if I have followed the best
practices, especially in terms of seq_file, error handling and locking.
I would appreciate any feedback.

I have do some simply testing using libfuse example [1]. It seems to
work well.

[1]: https://github.com/libfuse/libfuse/blob/master/example/passthrough_hp.cc

Signed-off-by: Chen Linxuan <chenlinxuan@uniontech.com>
---
Changes in v3:
- Apply some suggestions from Amir Goldstein
- Link to v2: https://lore.kernel.org/r/20250508-fusectl-backing-files-v2-0-62f564e76984@uniontech.com

Changes in v2:
- Void using seq_file private field as it seems that we can just simply
  returning fuse_backing_files_seq_state in start() and next()
- Apply some suggestions from Amir Goldstein:
  - Use idr_get_next() for iteration
  - Do fuse_backing_get/put(fb) around dereferencing fb->file
- Update fdinfo of fuse files
- Link to v1: https://lore.kernel.org/r/20250507032926.377076-2-chenlinxuan@uniontech.com

---
Chen Linxuan (3):
      fs: fuse: add const qualifier to fuse_ctl_file_conn_get()
      fs: fuse: add backing_files control file
      fs: fuse: add more information to fdinfo

 fs/fuse/control.c | 157 +++++++++++++++++++++++++++++++++++++++++++++++++-----
 fs/fuse/file.c    |  20 +++++++
 fs/fuse/fuse_i.h  |   2 +-
 3 files changed, 165 insertions(+), 14 deletions(-)
---
base-commit: d76bb1ebb5587f66b0f8b8099bfbb44722bc08b3
change-id: 20250508-fusectl-backing-files-6810d290e798

Best regards,
-- 
Chen Linxuan <chenlinxuan@uniontech.com>

On Fri, May 9, 2025 at 8:34 AM Chen Linxuan via B4 Relay
<devnull+chenlinxuan.uniontech.com@kernel.org> wrote:
>
> Please review this patch series carefully. I am new to kernel
> development and I am not quite sure if I have followed the best
> practices, especially in terms of seq_file, error handling and locking.
> I would appreciate any feedback.
>
> I have do some simply testing using libfuse example [1]. It seems to
> work well.
>
> [1]: https://github.com/libfuse/libfuse/blob/master/example/passthrough_hp.cc
>
> Signed-off-by: Chen Linxuan <chenlinxuan@uniontech.com>
> ---

Very nice work Chen!

Please give reviewers some more time to review before posting v4
and you do not have to post v4 on account of my minor comments
unless Miklos requests it.

One thing that now comes to mind is how lsof is going to use and present
this information?

I did not look at how lsof presents io_uring fixed files, but I assume that
an io_uring is always associated with a specific user process.
How does lsof display the io_uring files?

I guess with io_uring, lsof can list a pid which admin can kill to release the
open files?
This is not the case with displaying conn, because lsof is not designed
to list fuse conn.

Is there a way for userspace to get from conn to fuse server pid?

Even if there were a way, I think that the fuse connection and open
backing files can certainly outlive the killed fuse server process.

But still, in the common case, if lsof can blame the fuse server process,
in most cases, killing the fuse server process will release the backing files,
so it may be worth looking into this.

Thanks,
Amir.

On Fri, 9 May 2025 at 09:36, Amir Goldstein <amir73il@gmail.com> wrote:

> This is not the case with displaying conn, because lsof is not designed
> to list fuse conn.
>
> Is there a way for userspace to get from conn to fuse server pid?

Define "server pid".

One such definition would be

 "A fuse server is a process that has an open file descriptor
referring to a /dev/fuse instance."

This definition allows a mapping between tasks and fuse connections to
be established.  Note that this is not a 1:1 mapping.  Multiple
processes could have the same fuse fd (or a clone) open and one
process could have multiple different connections associated with it.

This might be sufficient for lsof if it can find out the connection
number from the fd.  E.g. adding "fuse_connection: N" to fdinfo would
work, I think.

Thanks,
Miklos

On Fri, May 9, 2025 at 6:23 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Fri, 9 May 2025 at 09:36, Amir Goldstein <amir73il@gmail.com> wrote:
>
> > This is not the case with displaying conn, because lsof is not designed
> > to list fuse conn.
> >
> > Is there a way for userspace to get from conn to fuse server pid?
>
> Define "server pid".
>
> One such definition would be
>
>  "A fuse server is a process that has an open file descriptor
> referring to a /dev/fuse instance."
>
> This definition allows a mapping between tasks and fuse connections to
> be established.  Note that this is not a 1:1 mapping.  Multiple
> processes could have the same fuse fd (or a clone) open and one
> process could have multiple different connections associated with it.
>
> This might be sufficient for lsof if it can find out the connection
> number from the fd.  E.g. adding "fuse_connection: N" to fdinfo would
> work, I think.

For getting from conn to fuse server pid, what about adding the server
pid to fuse's sysfs info? This use case has come up a few times in
production where we've encountered a stuck server and have wanted to
identify its pid. I have a patch on a branch I need to clean up and
send out for this, but it adds a new "info" file to
/sys/fs/fuse/connections/*/ where libfuse can write any identifying
info to that file like the server pid or name. If the connection gets
migrated to another process then libfuse is responsible for modifying
that to reflect the correct info.

Thanks,
Joanne

>
> Thanks,
> Miklos
>

On Tue, 13 May 2025 at 20:52, Joanne Koong <joannelkoong@gmail.com> wrote:

> For getting from conn to fuse server pid, what about adding the server
> pid to fuse's sysfs info? This use case has come up a few times in
> production where we've encountered a stuck server and have wanted to
> identify its pid. I have a patch on a branch I need to clean up and
> send out for this, but it adds a new "info" file to
> /sys/fs/fuse/connections/*/ where libfuse can write any identifying
> info to that file like the server pid or name. If the connection gets
> migrated to another process then libfuse is responsible for modifying
> that to reflect the correct info.

Fine, but then why not just write something in /var/run/fuse?

Thanks,
Miklos

On Wed, May 14, 2025 at 1:50 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Tue, 13 May 2025 at 20:52, Joanne Koong <joannelkoong@gmail.com> wrote:
>
> > For getting from conn to fuse server pid, what about adding the server
> > pid to fuse's sysfs info? This use case has come up a few times in
> > production where we've encountered a stuck server and have wanted to
> > identify its pid. I have a patch on a branch I need to clean up and
> > send out for this, but it adds a new "info" file to
> > /sys/fs/fuse/connections/*/ where libfuse can write any identifying
> > info to that file like the server pid or name. If the connection gets
> > migrated to another process then libfuse is responsible for modifying
> > that to reflect the correct info.
>
> Fine, but then why not just write something in /var/run/fuse?

Oh cool, I didn't know there's a /var/run directory. But I guess one
advantage of doing it in sysfs is that it'll work for unprivileged
servers whereas I think with /var/run/, there needs to be elevated
permissions to write to anything in that directory path.


Thanks,
Joanne

>
> Thanks,
> Miklos

On Thu, May 15, 2025 at 7:04 AM Joanne Koong <joannelkoong@gmail.com> wrote:

> But I guess one advantage of doing it in sysfs is that it'll work for
> unprivileged servers whereas I think with /var/run/, there needs
> to be elevated permissions to write to anything in that directory path.

I suggest something like $XDG_RUNTIME_DIR/libfuse for unprivileged servers.
It usually is something like /var/run/user/1000/libfuse.

Thanks,
Chen Linxuan

On Wed, May 14, 2025 at 8:17 PM Chen Linxuan <chenlinxuan@uniontech.com> wrote:
>
> On Thu, May 15, 2025 at 7:04 AM Joanne Koong <joannelkoong@gmail.com> wrote:
>
> > But I guess one advantage of doing it in sysfs is that it'll work for
> > unprivileged servers whereas I think with /var/run/, there needs
> > to be elevated permissions to write to anything in that directory path.
>
> I suggest something like $XDG_RUNTIME_DIR/libfuse for unprivileged servers.
> It usually is something like /var/run/user/1000/libfuse.

Cool, I think this works then.

Thanks,
Joanne
>
> Thanks,
> Chen Linxuan