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
