Bug 480052

Summary:	WARNING: unhandled amd64-freebsd syscall: 580
Product:	[Developer tools] valgrind	Reporter:	asomers
Component:	memcheck	Assignee:	Paul Floyd <pjfloyd>
Status:	RESOLVED FIXED
Severity:	normal	CC:	pjfloyd
Priority:	NOR
Version First Reported In:	3.22 GIT
Target Milestone:	---
Platform:	FreeBSD Ports
OS:	FreeBSD
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description asomers 2024-01-19 17:11:22 UTC

SUMMARY

memcheck does not handle the "fspacectl" syscall (syscall #580).


STEPS TO REPRODUCE
1.  Using FreeBSD 14/stable, 15.0-CURRENT, or 14.0-RELEASE with the tests distribution installed:
2.  cd /usr/tests/sys/fs/fusefs
3. valgrind --tool=memcheck ./fallocate --gtest_filter=Fspacectl.ok -v

OBSERVED RESULT

==14536== Memcheck, a memory error detector
==14536== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==14536== Using Valgrind-3.22.0.GIT and LibVEX; rerun with -h for copyright info
==14536== Command: ./fallocate --gtest_filter=Fspacectl.ok -v
==14536== 
Note: Google Test filter = Fspacectl.ok
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from Fspacectl
[ RUN      ] Fspacectl.ok
INIT        ino= 0
ACCESS      ino= 1 mask=0x1
LOOKUP      ino= 1 some_file.txt
OPEN        ino=42 flags=0x2
--14536-- WARNING: unhandled amd64-freebsd syscall: 580
--14536-- You may be able to write your own handler.
--14536-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--14536-- Nevertheless we consider this a bug.  Please report
--14536-- it at http://valgrind.org/support/bug_reports.html.
/usr/home/somers/src/freebsd.org/src/tests/sys/fs/fusefs/fallocate.cc:335: Failure
Expected equality of these values:
  0
  fspacectl(fd, 1, &rqsr, 0, &rmsr)
    Which is: -1

EXPECTED RESULT

The test should pass

SOFTWARE/OS VERSIONS
FreeBSD 14.0-RELEASE and later.

ADDITIONAL INFORMATION

Comment 1 Paul Floyd 2024-01-20 07:01:05 UTC

This should be in FreeBSD 13.1+

580	AUE_FSPACECTL	STD|CAPENABLED {
		int fspacectl(
		    int fd,
		    int cmd,
		    _In_ const struct spacectl_range *rqsr,
		    int flags,
		    _Out_opt_ struct spacectl_range *rmsr,

Comment 2 asomers 2024-01-20 14:07:11 UTC

No, it isn't in 13.1.  It first appeared in 14.0.  You can check from the man pages browser here: https://man.freebsd.org/cgi/man.cgi?query=fspacectl .

Comment 3 Paul Floyd 2024-01-20 17:58:28 UTC

Bah yes. Syscall 580 was a hole in the numbering until FreeBSD 14.

Comment 4 Paul Floyd 2024-01-20 20:20:07 UTC

The missing syscall should be fixed with

commit 3cacde0ca261196031cb84b22ad427483bae057e (HEAD -> master, origin/master, origin/HEAD)
Author: Paul Floyd <pjfloyd@wanadoo.fr>
Date:   Sat Jan 20 21:14:37 2024 +0100

    Bug 480052 - WARNING: unhandled amd64-freebsd syscall: 580

I still get a lot of errors and the googletest fails

Comment 5 asomers 2024-01-20 23:52:00 UTC

Thanks for the quick fix!  It works for me.  As for the other failures, they seem unrelated.  It seems like the server thread (there are two threads) hangs when reading from /dev/fuse.  The hangs only happen with some test cases and not others.  I can't see any pattern behind which test cases hang and which don't.  Is there any way that valgrind could introduce a deadlock?  Perhaps the read from /dev/fuse triggers a signal, but the signal handler can't run because the first thread is blocked in the fspacectl syscall?

Comment 6 Paul Floyd 2024-01-21 19:47:20 UTC

Valgrind is unlikely to cause a deadlock.

However, it can bring out race conditions. Firstly, it is considerably slower. Secondly, it runs effectively as though there were a single CPU (similar to Python and its GIL). So code that works by accident because one thread 'always' does something before another can get caught out.