3 ms·
The glibc test suite contains a few tiny FUSE file systems. For example, there is one that just happens to contain every file that mkstemp attempts to create, f
by fweimer 4mo ago
The glibc test suite contains a few tiny FUSE file systems. For example, there is one that just happens to contain every file that mkstemp attempts to create, for a test that exercises the O_CREAT|O_EXCL failure path. Like the Rust fuser crate, it uses the kernel API directly. The tests are slightly brittle because sometimes we encounter a new LSM that triggers unexpected file system operations, but it's not too bad overall.
What I found funny when I discovered it is that you can create a thread in the same process that provides the FUSE file system implementation for this very process. It makes it much easier to write certain tests, especially debugging. We had to teach valgrind that more system calls effectively perform callbacks into the same process, but fortunately valgrind already had a FUSE_COMPATIBLE_MAY_BLOCK mechanism for that.
- rigonkulous 4mo agoIndeed, the glibc test suite .. plus a suite of BPF scripts for instrumenting .. can provide a great deal of information about how things are running in a target OS .. if you give a process its own filesystem and then rig up a bpf console with some hot gnuplot, you can get some very significant details, at the i/o level, about the heuristics of an application, library, user-space module/plugin, etc... It used to be you had to wade through massive logs though, if you don't get things quite tweaked - but in the AI/ML agent sense of things these days, just describe what you need, FUSE the right nodes, and run the bpf scripts, yo ..
- deleted 4mo ago[deleted]
- paulf38 4mo agoIs that something that should be merged to upstream Valgrind?
- fweimer 4mo agoEverything we need is already upstream. I think the changes were: commit 0690dc39644d15fc89813419ffcdf9754b098260 Author: Mark Wielaard <mark@klomp.org> Date: Sun Sep 22 23:24:34 2024 +0200 Implement /proc/self/exe readlink[at] fallback in POST handler Calling the readlink[at] syscall directly from the PRE handler defeats the FUSE_COMPATIBLE_MAY_BLOCK (SfMayBlock) flag. Add a POST handler that only explicitly calls the readlink[at] handler for the /proc/self/exe fallback (this should be fine unless /proc is also implemented as fuse in this process). Adjust readlink[at] GENX_ and LINX_ syswrap macros to GENXY and LINXY. https://bugs.kde.org/show_bug.cgi?id=493507 commit ddf397c024c80382f7a2f3a0d46d58fb839eef96 Author: Mark Wielaard <mark@klomp.org> Date: Sat Sep 21 22:27:24 2024 +0200 Add missing FUSE_COMPATIBLE_MAY_BLOCKs Various syscalls (in particular "at" variants) PRE handlers were missing a FUSE_COMPATIBLE_MAY_BLOCK statement. Add it to the generic PRE handlers of access and statfs64. And the linux PRE handlers of mknodat, fchownat, futimesat, utimensat, utimensat_time64, renameat, renameat2, readlinkat, fchmodat, fchmodat2, faccessat and faccessat2. https://bugs.kde.org/show_bug.cgi?id=493454