tools/create-openbsd: bump up the limits for syz-bit

[blackgnezdo]

As syz-bot became much more aggressive about resource usage lately it started running over the limits and is getting blocked. Give it all the rope it wants. There's nothing else on the VM anyway.

Used the vmd class as it is given the most memory in login.conf.

[blackgnezdo]

@a-nogikh could you try making this same change locally in /etc/rc.local to confirm it's working as intended before rebuilding the images? I didn't have a handy environment to test this locally so my confidence in this fix is not too high.

[a-nogikh]

Now it fails with "out of memory", which is very strange -- the VM has 64GB.

+ mount /syzkaller
+ su -l syzkaller
+ << EOF2 
+ ulimit -n 1024
+ mkdir -p /syzkaller/go-cache
+ export GOCACHE=/syzkaller/go-cache
+ test -d /syzkaller/gopath/src/github.com/google/syzkaller
+ cd /syzkaller/gopath/src/github.com/google/syzkaller
+ gmake ci
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
go list -f '{{.Stale}}' ./sys/syz-sysgen | grep -q false || go install ./sys/syz-sysgen
gmake .descriptions
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
bin/syz-sysgen
fatal error: runtime: out of memory

runtime stack:
runtime.throw({0x66e16d?, 0x0?})
	/usr/local/go/src/runtime/panic.go:1023 +0x5c fp=0x6fbe04274ad8 sp=0x6fbe04274aa8 pc=0x43ad5c
runtime.sysMapOS(0xc059c00000, 0xc00000)
	/usr/local/go/src/runtime/mem_bsd.go:81 +0x116 fp=0x6fbe04274b18 sp=0x6fbe04274ad8 pc=0x41af36
runtime.sysMap(0xc059c00000, 0xc00000, 0x6fbe04274ad0?)
	/usr/local/go/src/runtime/mem.go:155 +0x34 fp=0x6fbe04274b38 sp=0x6fbe04274b18 pc=0x41acf4
runtime.(*mheap).grow(0x962e20, 0x500?)
	/usr/local/go/src/runtime/mheap.go:1534 +0x236 fp=0x6fbe04274ba8 sp=0x6fbe04274b38 pc=0x42d6f6
runtime.(*mheap).allocSpan(0x962e20, 0x500, 0x0, 0x1)
	/usr/local/go/src/runtime/mheap.go:1246 +0x2e6 fp=0x6fbe04274c48 sp=0x6fbe04274ba8 pc=0x42ce26
runtime.(*mheap).alloc.func1()
	/usr/local/go/src/runtime/mheap.go:964 +0x5c fp=0x6fbe04274c90 sp=0x6fbe04274c48 pc=0x42c79c
runtime.systemstack(0x959ce0)
	/usr/local/go/src/runtime/asm_amd64.s:509 +0x4a fp=0x6fbe04274ca0 sp=0x6fbe04274c90 pc=0x46e06a

[blackgnezdo]

Now it fails with "out of memory", which is very strange -- the VM has 64GB.

Right, the limit is not the physical memory but the one imposed by the kernel as controlled by ulimit. BSDs have historically placed these limits at non-infinity making them more resistant to certain kinds of failures.

I pushed an updated commit with a different ulimit line. I should have kept the -d we had before (I misread the default settings and removed this in error). At least now I doubled the amount of memory to be used by syz-bot and friends.

[a-nogikh]

It has indeed become better -- syz-ci is up.

But it failed to build the latest syzkaller

executor/executor_bsd.h:49:9: error: use of undeclared identifier 'syscall'
        return __syscall(c->sys_nr, a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7], a[8]);
               ^
executor/common_bsd.h:95:19: note: expanded from macro '__syscall'
#define __syscall syscall
                  ^
1 error generated.

And has posted a weird bug: https://syzkaller.appspot.com/bug?extid=6a043f618cde823a3d93