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

[Mark W. <ma...@kl...>]

Hi Florian,

On Sat, Sep 21, 2024 at 11:40:43PM +0200, Florian Weimer wrote:
> * Mark Wielaard:
> > 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

Interesting. I see valgrind reports:

==1530594== Syscall param mount(type) points to unaddressable byte(s)
==1530594==    at 0x498C8FE: mount (syscall-template.S:117)
==1530594==    by 0x10EC4E: support_enter_mount_namespace (support_enter_mount_namespace.c:36)
==1530594==    by 0x10BDB4: support_fuse_init (support_fuse.c:236)
==1530594==    by 0x10B095: do_test (tst-support_fuse.c:238)
==1530594==    by 0x10DF81: support_test_main (support_test_main.c:413)
==1530594==    by 0x10A67A: main (test-driver.c:171)
==1530594==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

But in this case we should ignore the mount (filesystem)type argument.

> 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.

You are right. It is the plain readlink syscall. The problem is that
valgrind tries to intercept it for /proc/self/exe so it returns the
actual binary instead of the valgrind "wrapper". Because of that it
seems to do a direct, "blocking" syscall. I am working on a
workaround/fix.

> > 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.

Yes, you are probably right.

> 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;

Nice catch. We seem to handle the File Locks and Open File Descriptor
Locks mostly identical except here.

Thanks,

Mark