Hi Geert,
On 15/06/21 7:51 pm, Geert Uytterhoeven wrote:
Hi Michael,
On Tue, Jun 15, 2021 at 1:14 AM Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
On 15/06/21 11:04 am, John Paul Adrian Glaubitz wrote:
On 6/15/21 12:11 AM, Michael Schmitz wrote:
working on entry.S recently, I was reminded of this one. It's never been applied, and I can't find a trace of it in my tree.
Not sure how far Adrian got with seccomp support testing, so I'm uncertain this is still of interest ...
I still have a fork of libseccomp with m68k support and my SH support patch
was merged upstream.
So, if you guys can get the kernel bits in place, I can take care of libseccomp.
Thanks - what (aside from my old patch) is still missing on the kernel
side?
IIRC, it wasn't working well yet. Reading the archives, due to some incorrect
return value somewhere?
As I recall it, it wasn't clear what the correct return value should be.
Seccomp uses -1 to signal syscall abort, but there is considerable
variation among architectures about what signals a syscall abort. I've
seen tests for return code > NR_syscalls, != 0, or == -1. Some
architectures allow the return code to be used as the new syscall number
(no idea how that works, with the argument list unchanged?).
But no matter - I'll change the test and resubmit.
Cheers,
Michael
Gr{oetje,eeting}s,
Geert
