syz-ci: uses wrong syzkaller revision to test patches

[dvyukov]

From email report:

"#syz test" consistently fails for this syzbot bug:
  https://syzkaller.appspot.com/bug?extid=fc026e87558558f75c00
  (kernel BUG in clear_inode, F2FS)

The error is:
  "unknown enabled syscall: syz_memcpy_off$IO_URING_METADATA_FLAGS"
  "unknown enabled syscall: syz_memcpy_off$IO_URING_SQE_FLAGS"

The bug's manager config (ci2-upstream-fs / ci-snapshot-upstream-root)
references syz_memcpy_off$IO_URING* in enabled_syscalls, but these
were renamed to syz_io_uring_modify_offsets$* in the current syzkaller
tree. This causes ParseEnabledSyscalls to fail before the VM boots.

Failed test attempts:
  2026/03/28 15:41 - error (9 min)
  2026/03/28 15:47 - error (9 min)
  2026/03/28 16:17 - error (9 min)

Thanks,
Taerang Kim

example log:
https://syzkaller.appspot.com/x/error.txt?x=112cef72580000

syz-ci is supposed to use the repro only via syz-execprog built on the right revision. But somehow syz-ci uses wrong revision to parse the reproducer. Perhaps we parse it somewhere in syz-ci itself?...
This never happened before, so may be introduced by a recent change.

[a-nogikh]

FTR our ci2-upstream-fs instance broke as well after the io_uring descriptions change (just fixed).

I think we are building the right revision, but the problem is that we call mgrconfig.Complete in env.Test():

syzkaller/pkg/instance/instance.go

Lines 266 to 268 in dcaebc5

	if err := mgrconfig.Complete(env.cfg); err != nil {
	return nil, err
	}

[a-nogikh]

Or maybe we actually don't need to change anything at all. The code checks the currently configured syscall set for a manager against the syscalls supported in the current revision, which should normally work.

[dvyukov]

FTR our ci2-upstream-fs instance broke as well after the io_uring descriptions change (just fixed).

How does it break?

I think we are building the right revision, but the problem is that we call mgrconfig.Complete in env.Test():
Or maybe we actually don't need to change anything at all. The code checks the currently configured syscall set for a manager
against the syscalls supported in the current revision, which should normally work.

Does it use the config for the tested program in any way? That would be wrong. The revision of the syz-ci code cannot understand the program format.

[a-nogikh]

How does it break?

Our enable_syscalls config for the fs instance directly mentioned a syscall that no longer exists. Therefore it was failing to start due to unknown enabled syscall.

Does it use the config for the tested program in any way? That would be wrong.

I don't see where it would parse the program. It only cares about the syz-manager config, which became broken (see above).

[dvyukov]

Then perhaps it's the same issue as #7014, wrong syzkaller binaries would lead to this failure mode.

[a-nogikh]

No, these are separate. The failure happened on the syz-ci side that was doing the job, not on the syz-execprog or syz-manager side.

[dvyukov]

Ah, it wasn't related to the reproducer at all, right? So the testing is fixed now, then, right?
How can we prevent this from happening in the future? Renaming/removing syscalls is likely to happen in the future.

[a-nogikh]

Ah, it wasn't related to the reproducer at all, right? So the testing is fixed now, then, right?

Yes

How can we prevent this from happening in the future? Renaming/removing syscalls is likely to happen in the future.

We probably still want to be strict about enable_syscalls.

Testing all PRs against all our syz-ci configs would be tricky to organize.

Maybe we could extend how syz-ci tests the new syzkaller revision it builds and not just run go test, but also check that all syz-manager configs are valid? Then, such problems would manifest themselves not as broken managers or broken #syz test, but as syzkaller build errors.

[dvyukov]

Maybe we could extend how syz-ci tests the new syzkaller revision it builds and not just run go test, but also check that all syz-manager configs are valid? Then, such problems would manifest themselves not as broken managers or broken #syz test, but as syzkaller build errors.

Yes, this looks much better failure mode.