consensus/ethash: avoid runtime errors due to OOD on mmap writes

[holiman]

This PR avoids a pretty rare crash.

Some more info here: edsrzf/mmap-go#12 (comment) .

When we map a file for generating the DAG, we do a simple truncate to e.g. 1Gb. This is fine, even if we have nowhere near 1Gb disk available, as the actual file doesn't take up the full 1Gb, merely a few bytes. When we start generating into it, however, it eventually crashes with a unexpected fault address .

Examples:

• SIGBUS panic while the full DAG generation #21928
• unexpected fault #23453

There are two ways we can fix this, the simplest being to use the fallocate linux system call.
The second way is to convert the internals of ethash; instead of generating into a []byte, we generate into an interface which supports WriteAt. Then we can first generate into a file (or into a wrapped memory slice), and later do a readonly-mmap on it.

This PR implements the first approach. I tried the second approach, but it becomes a pretty large refactor, especially since it also touches the cache generator (which uses the same schema), and the cache-generator is not as 'linear' -- it reads from self in a way which the DAG-generator does not, and thus is more difficult to convert this way. In the end, I thought it seems a bit wasteful to do a major refactoring of ethash at this point.

This PR also fixes an over-allocation that could happen if the mmap fails, and we generate the dag in-memory, and does some more cleanup in case of failures.

Re testing

I found this error when I tried running go test . -run - -bench BenchmarkHashimotoFullMmap/WithLock -v. It generates the dag to the system temp, which in my case was limited to 1Gb. Without this fix, the benchmark crashed, but it runs fine with this fix.

Re platforms

I got the supported-platform info from this

[user@work syscall]$ grep Fallocate * 
grep: js: Is a directory
syscall_linux.go://sys	Fallocate(fd int, mode uint32, off int64, len int64) (err error)
zsyscall_linux_386.go:func Fallocate(fd int, mode uint32, off int64, len int64) (err error) {
zsyscall_linux_amd64.go:func Fallocate(fd int, mode uint32, off int64, len int64) (err error) {
zsyscall_linux_arm.go:func Fallocate(fd int, mode uint32, off int64, len int64) (err error) {
zsyscall_linux_arm64.go:func Fallocate(fd int, mode uint32, off int64, len int64) (err error) {
zsyscall_linux_mips.go:func Fallocate(fd int, mode uint32, off int64, len int64) (err error) {
zsyscall_linux_mips64.go:func Fallocate(fd int, mode uint32, off int64, len int64) (err error) {
zsyscall_linux_mips64le.go:func Fallocate(fd int, mode uint32, off int64, len int64) (err error) {
zsyscall_linux_mipsle.go:func Fallocate(fd int, mode uint32, off int64, len int64) (err error) {
zsyscall_linux_ppc64.go:func Fallocate(fd int, mode uint32, off int64, len int64) (err error) {
zsyscall_linux_ppc64le.go:func Fallocate(fd int, mode uint32, off int64, len int64) (err error) {
zsyscall_linux_riscv64.go:func Fallocate(fd int, mode uint32, off int64, len int64) (err error) {
zsyscall_linux_s390x.go:func Fallocate(fd int, mode uint32, off int64, len int64) (err error) {

[gballet]

In https://pkg.go.dev/syscall they say: Deprecated: this package is locked down. Callers should use the corresponding package in the golang.org/x/sys repository instead. That is also where updates required by new systems or versions should be applied. See https://golang.org/s/go1.4-syscall for more information.

[gballet]

do you need to specify all the possible $GOARCH in there? A simple

Suggested change

	//go:build linux && (386 || amd64 || arm || arm64 || mips || mips64 || mips64le || ppc || pcc64 || pcc64le || riscv64 || s390x || sparc64)
	//go:build linux

should work, I think, as I see no reason for fallocate not to be present for a given architecture.

[holiman]

Hm, indeed, it is present in all files. I was confused because they didn't put it in in syscall_linux.go, but instead added it individually in all files.

[holiman]

Fixed, ptal

[holiman]

@gballet lgty?

[holiman]

Note for reviewers: check line 330, and you'll see that this is the same as what's used already whenever we don't use disk-based dag.