Re: [PATCH] m68k/kernel - wire up syscall_trace_enter/leave for m68k

[Michael Schmitz <schmitzmic@gmail.com>]

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@gmail.com> 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
>