Re: [PATCH 2/3] x86/asm/entry/32: Remove most of SYSCALL32 code, part 1

[Ingo Molnar <mingo@kernel.org>]

* Denys Vlasenko <dvlasenk@redhat.com> wrote:

> SYSCALL32 code is nearly identical to SYSCALL32, except for initial
> section. Merge them.
> 
> The removal is split into two parts, to make review eaiser. This is part 1.
> 
> auditsys_entry_common and auditsys_exit macros are indented one more tab without
> any changes. This prevents diff from becoming unreadable.
> They will be removed in part 2.
> 
> Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
> CC: Ingo Molnar <mingo@kernel.org>
> CC: Linus Torvalds <torvalds@linux-foundation.org>
> CC: Krzysztof A. Sobiecki <sobkas@gmail.com>
> CC: Steven Rostedt <rostedt@goodmis.org>
> CC: Borislav Petkov <bp@alien8.de>
> CC: "H. Peter Anvin" <hpa@zytor.com>
> CC: Andy Lutomirski <luto@amacapital.net>
> CC: Oleg Nesterov <oleg@redhat.com>
> CC: Frederic Weisbecker <fweisbec@gmail.com>
> CC: Alexei Starovoitov <ast@plumgrid.com>
> CC: Will Drewry <wad@chromium.org>
> CC: Kees Cook <keescook@chromium.org>
> CC: x86@kernel.org
> CC: linux-kernel@vger.kernel.org
> ---
>  arch/x86/entry/entry_64_compat.S | 237 +++++++++++----------------------------
>  1 file changed, 63 insertions(+), 174 deletions(-)

Yeah, so I realize that this is already a 'cleaner', split up version of your 
original change - but the diffstat is still way too large: _please_ split it up 
into 2-3 further steps to make each step really, utterly obvious.

As you must have experienced it with recent regressions in the x86 entry code, the 
smaller our assembly changes, the easier our job of doing a revert is, when such a 
change regresses ...

I don't care if it ends up being 5-7 patches - that's far more preferable to 
having to decode difficult looking regressions.

For example in hindsight I regret that I did not insist on further splitting up 
this commit:

  53e9accf0f76 ("x86/asm/entry/32: Do not use R9 in SYSCALL32 entry point")

and that was a small patch already:

 arch/x86/entry/ia32entry.S | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

I'm not going to make that mistake again: if you want to change the x86 assembly 
code, you need to learn to decompose dangerous changes into maximally split up, 
atomic, bisectable steps.

Agreed?

Thanks,

	Ingo