-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
strange behaviour on v4.4 kernels with libseccomp v2.3.1 #40
Comments
xnox
added a commit
to xnox/libseccomp
that referenced
this issue
Jun 10, 2016
…numbers A bunch of syscalls got converted from pseudo to real syscall numbers. And the table now corectly uses pseudo syscall numbers where needed (e.g. accept, send) thus there is no need to repeat these overrides in the x86_syscall_resolve_name() which has now got out of sync with the table. Fixes seccomp#40 Signed-off-by: Dimitri John Ledkov <[email protected]>
Actually this is maybe a non-bug, given 73d83e4 |
silly me
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I'm in a i686 chroot, and using scmp_sys_resolver I see multiple regression with syscall look-ups. The tests I run is to check that number->name->number lookups are roundtrip safe, and they appear to not be as per below:
My expectation was for the output to just be:
I see this regression for other syscalls too, on i686 and on s390x architectures.
amd64 and ppc64el pass correctly.
s390x failures:
i686 failures:
Are my expectation somehow wrong? is v4.5 kernel required for v2.3.1 release? Is there a bug in compat between kernel versions?
The text was updated successfully, but these errors were encountered: