[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1a0ea2f0-d817-7261-b17e-c1f5f3a767e4@gmail.com>
Date: Wed, 12 Jan 2022 20:54:37 +1300
From: Michael Schmitz <schmitzmic@...il.com>
To: Finn Thain <fthain@...ux-m68k.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
Al Viro <viro@...iv.linux.org.uk>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux-Arch <linux-arch@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
Kees Cook <keescook@...omium.org>,
Linux API <linux-api@...r.kernel.org>,
linux-m68k <linux-m68k@...ts.linux-m68k.org>
Subject: Re: [PATCH 08/17] ptrace/m68k: Stop open coding ptrace_report_syscall
Hi Finn,
Am 12.01.2022 um 16:32 schrieb Finn Thain:
> On Wed, 12 Jan 2022, Michael Schmitz wrote:
>
>>
>> I seem to recall we also tested those on your 040 and there was no
>> regression there, but I may be misremembering that.
>>
>
> I abandoned that regression testing exercise when unpatched mainline
> kernels began failing on that machine. I'm in the process of setting up a
> different 68040 machine.
>
Thanks for refreshing my memory!
Splitting my first patch as suggested by Al in order to defer handling
of the syscall_trace_enter() return code would achieve what Geert
suggested (eliminate m68k syscall_trace() altogether) without risk of
regression. This would need to replace Eric's patch 8.
Do you want me to send such a version based on my old patch series, or
would you rather prepare that yourself, Eric?
Cheers,
Michael
Powered by blists - more mailing lists