Re: [Valgrind-developers] valgrind --track-fds, fuse and other issues

[Florian W. <fw...@re...>]

* Mark Wielaard:

> Hi Florian,
>
> On Sat, Sep 21, 2024 at 07:40:30PM +0200, Florian Weimer wrote:
>> > Please let me know if this still doesn't work. This hint hasn't been
>> > updated in a long time and there might be some newer syscalls that
>> > should enable this hint, but don't (yet).
>> 
>> Very interesting!  It gets past a lot of things, but support for the
>> readlink system call appears to be missing.  Nevertheless, it already
>> found test bugs:
>> 
>>   support: Fix memory leaks in FUSE tests
>>   <https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=455c7622835d>
>
> Very nice. Happy it worked (partially).
>
> The readlink system call should work, but I see the readlinkat system
> call doesn't have a fuse marker in the valgrind PRE handler.

That's odd.  It's really using the readlink system call as far as I can
tell.

To reproduce:

git clone --depth=1 https://sourceware.org/git/glibc.git
cd glibc
mkdir build
cd build
../configure --prefix=/usr --disable-nscd --disable-mathvec MAKEINFO=:
make -j`nproc`
make -j`nproc` subdirs=support check run-built-tests=no

On Fedora 40 (glibc 2.39), it's still possible to run the test directly
because the version difference is not too great, so you can run the test
directly:

valgrind --leak-check=full --sim-hints=fuse-compatible \
  support/tst-support_fuse --direct

If you terminate the FUSE service using

echo 1 | tee /sys/fs/fuse/connections/*/abort

the failure strongly suggests that readlink is at fault:

error: xreadlink.c:34: readlink ("/tmp/glibc-tst-fuse.264432.1/264432.1//symlink"): Software caused connection abort

And strace shows there is really a readlink system call.

> I found several other (at) syscalls missing the fuse marker so I filed
> a bug and submitted a patch:
> https://bugs.kde.org/show_bug.cgi?id=493454

The copy_file_range system call has a FUSE event, too.  If I understand
it correctly, it should probably be marked as blocking unconditionally
because as a file system operation, it can potentially take quite some
time.

Furthermore, I think fcntl and fcntl64 do not handle the OFD locks:

#  if defined(VGP_x86_linux)
   if (ARG2 == VKI_F_SETLKW || ARG2 == VKI_F_SETLKW64)
#  else
   if (ARG2 == VKI_F_SETLKW)
#  endif
      *flags |= SfMayBlock;

Thanks,
Florian