Well this change made the ID 392 "known" to all architectures (in a try to sync numbers across everywhere) but it fails on those it isn't implemented (32bit, ppc, s390x + sparc which we don't have).
The path registering these calls goes seccomp_rule_add -> seccomp_rule_add_array -> db_col_valid -> _syscall_valid -> db_col_rule_add <- still -204/392 -> _db_rule_new -> db_col_transaction_start <- dups old rule (-201) ITERATES -> arch_filter_rule_add -> arch_syscall_translate -> arch_syscall_resolve_num <- returns "semop" for -201 -> arch_syscall_resolve_name <- returns -201 for "semop" Returns RC=0 (db_col_transaction_start) The above defined the transaction start -> arch_filter_rule_add <- this adds the new rule -204/392 -> arch_syscall_translate -> arch_syscall_resolve_num Good case returns "semtimedop" for Bad case returns 0x0 for 392 From here it now returns -EFAULT (=> -14) and things break So we enter: Good: Breakpoint 14, s390x_syscall_resolve_num (num=-204) at arch-s390x-syscalls.c:533 Bad: Breakpoint 13, s390x_syscall_resolve_num (num=392) at arch-s390x-syscalls.c:533 This searches the table s390x_syscall_table and fails to find 392, from there things break. The worst is, that "semtimedop" is there, but with __PNR_semtimedop as number. As it used to have no number yet when last time generated. If it would use __NR_semtimedop instead of __PNR_semtimedop it might even work as-is. I'm not sure if src/arch-s390x-syscalls.c is allowed to use include/seccomp.h (where these compat defines are). I need to suggest that upstream (or check if a change exists) Summary of the above: - kernel change defined numbers for all calls (implemented or not) - due to that no more the fallback "#define __PNR_semtimedop -204" but provided 392 is used - arch_syscall_translate tries to translate 392 in the context of the native architecure to the provided architecture and fails - src/arch-s390x-syscalls.c contains syscall tables derived from 4.15-rc7 which need to be updated - Definitions in this table should use __NR_ instead of __PNR_ to get the kernel value once it is defined (will be ==__PNR when not defined) - Even if not using __NR it needs a redefine for newer kernels -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849785 Title: FTBFS on i386/ppc64/s390x (Eoan+Focal) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1849785/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs