go: cmd/link/internal/ld: TestFallocate consistently failing on freebsd-riscv64-unmatched
https://build.golang.org/log/81f8a8d0ec2511d322c9e2f8d9ad3b170fc33866:
--- FAIL: TestFallocate (0.00s)
fallocate_test.go:60: unexpected disk usage: got 1 blocks, want at least 2048
fallocate_test.go:60: unexpected disk usage: got 1 blocks, want at least 4096
fallocate_test.go:60: unexpected disk usage: got 1 blocks, want at least 6144
FAIL
FAIL cmd/link/internal/ld 45.438s
Looks like the same failure mode as #42005, but I’m filing a separate issue because this may be resolved on this particular builder by either reconfiguring the builder or adding a test skip.
(attn @mengzhuo; CC @golang/freebsd)
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 22 (21 by maintainers)
https://man.freebsd.org/cgi/man.cgi?query=posix_fallocate&sektion=2&n=1 says:
So I think the syscall wrapper needs to be checking the
r1
result from the call for the error, rather than theerr
result.@bcmills Right, I’ll adjust the CL.
Yes, I think so. Though I was using
mksyscall.go
fromx/sys/unix
, but that has the same logic:https://cs.opensource.google/go/x/sys/+/master:unix/mksyscall.go;l=237-247
I’m not sure how truss and and clang implement this 😦
@bcmills you’re right! We can all blame OpenGroup for this 😕
Something still doesn’t make sense. The freebsd-riscv64-unmatched builder exhibits the ZFS block size test failure, but the system call there presumably returns EINVAL (as seen when running the test manually on an amd64 with a ZFS filesystem). And for Go to match the C truss output, we’d need to do
syscall.Syscall6(posixFallocateTrap, uintptr(fd), uintptr(size>>32), uintptr(off), uintptr(off>>32), uintptr(size), uintptr(size>>32))
Oh! This is probably related to CL 479715 (attn @tklauser).
out.Mmap
doesfallocate
https://cs.opensource.google/go/go/+/master:src/cmd/link/internal/ld/outbuf_mmap.go;l=23 (out.Mmap
is not just a plain syscall)