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)

Most upvoted comments

https://man.freebsd.org/cgi/man.cgi?query=posix_fallocate&sektion=2&n=1 says:

If successful, posix_fallocate() returns zero. It returns an error on failure, without setting errno.

So I think the syscall wrapper needs to be checking the r1 result from the call for the error, rather than the err result.

https://man.freebsd.org/cgi/man.cgi?query=posix_fallocate&sektion=2&n=1 says:

If successful, posix_fallocate() returns zero. It returns an error on failure, without setting errno.

So I think the syscall wrapper needs to be checking the r1 result from the call for the error, rather than the err result.

@bcmills Right, I’ll adjust the CL.

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

@tklauser there’s a comment in about alignment in syscall/mksyscall.pl:

https://github.com/golang/go/blob/f62c9701b4bc61da6a5f4db8ef81d816f112430e/src/syscall/mksyscall.pl#L216-L227

Is that where the 0 in your new CL coming from?

Yes, I think so. Though I was using mksyscall.go from x/sys/unix, but that has the same logic:

https://cs.opensource.google/go/x/sys/+/master:unix/mksyscall.go;l=237-247

And then truss or clang just use the actual value as an optimization?

I’m not sure how truss and and clang implement this 😦

So I think the syscall wrapper needs to be checking the r1 result from the call for the error, rather than the err result.

@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 does fallocate 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)