Re: [PATCH 08/17] ptrace/m68k: Stop open coding ptrace_report_syscall

[Michael Schmitz]

Hi Finn,

Am 12.01.2022 um 11:42 schrieb Finn Thain:
> On Tue, 11 Jan 2022, Michael Schmitz wrote:
> > > In fact Michael did so in "[PATCH v7 1/2] m68k/kernel - wire up
> > > syscall_trace_enter/leave for m68k"[1], but that's still stuck...
> > >
> > > [1]
> > > https://lore.kernel.org/r/1624924520-17567-2-git-send-email-schmitzmic@xxxxxxxxx/
> >
> > That patch (for reasons I never found out) did interact badly with
> > Christoph Hellwig's 'remove set_fs' patches (and Al's signal fixes which
> > Christoph's patches are based upon). Caused format errors under memory
> > stress tests quite reliably, on my 030 hardware.
>
> Those patches have since been merged, BTW.

Yes, that's why I advised caution with mine.

> > Probably needs a fresh look - the signal return path got changed by Al's
> > patches IIRC, and I might have relied on offsets to data on the stack
> > that are no longer correct with these patches. Or there's a race between
> > the syscall trap and signal handling when returning from interrupt
> > context ...
> >
> > Still school hols over here so I won't have much peace and quiet until
> > February.
>
> So the patch works okay with Aranym 68040 but not Motorola 68030? Since

Correct - I seem to recall we also tested those on your 040 and there 
was no regression there, but I may be misremembering that.

> there is at least one known issue affecting both Motorola 68030 and Hatari
> 68030, perhaps this patch is not the problem. In anycase, Al's suggestion

I hadn't ever made that connection, but it might be another explanation, 
yes.

> to split the patch into two may help in that testing two smaller patches
> might narrow down the root cause.

That's certainly true.

What's the other reason these patches are still stuck, Geert? Did we 
ever settle the dispute about what return code ought to abort a syscall 
(in the seccomp context)?

Cheers,

	Michael