On Fri, May 9, 2025 at 4:43 PM Chen Linxuan <chenlinxuan@xxxxxxxxxxxxx> wrote: > > On Fri, May 9, 2025 at 10:00 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > On Fri, 9 May 2025 at 08:34, Chen Linxuan via B4 Relay > > <devnull+chenlinxuan.uniontech.com@xxxxxxxxxx> wrote: > > > > > > From: Chen Linxuan <chenlinxuan@xxxxxxxxxxxxx> > > > > > > Add a new FUSE control file "/sys/fs/fuse/connections/*/backing_files" > > > that exposes the paths of all backing files currently being used in > > > FUSE mount points. This is particularly valuable for tracking and > > > debugging files used in FUSE passthrough mode. > > > > This is good work, thanks. > > > > My concern is that this is a very fuse specific interface, even though > > the problem is more generic: list hidden open files belonging to a > > kernel object, but not installed in any fd: > > > > - SCM_RIGHTS > > - io_uring > > Note that io_uring has already exposed information about fixed files > in its fdinfo. > > > - fuse > > > > So we could have a new syscall or set of syscalls for this purpose. > > But that again goes against my "this is not generic enough" pet peeve. > > > > So we had this idea of reusing getxattr and listxattr (or implementing > > a new set of syscalls with the same signature) to allow retrieving a > > hierarchical set of attributes belonging to a kernel object. This one > > would also fit that pattern, so... > > > > Thoughts? I remember that there was some push back on this idea. If there was no push back, you probably wouldn't have written listmount/statmount... so I am a bit concerned about sending Chen down this rabbit hole. I think that for lsof, any way we present the information in fdinfo that is parsable would be good enough for lsof to follow. We could also list a full copy of backing_files table in fdinfo of all the /dev/fuse open files, that will give lsof the pid of fuse server in high likelihood. But this is not very scalable with a large number of backing_files. hmm. Is it a bad idea to merge the connections/N/backing_files code anyway at least for debugging? The extra fdinfo in patch 3 is just useful. I don't see why we should not add it regardless of the standard way to iterate all backing_files. Thanks, Amir.
