* Denys Vlasenko <dvlas...@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 <dvlas...@redhat.com>
> CC: Ingo Molnar <mi...@kernel.org>
> CC: Linus Torvalds <torva...@linux-foundation.org>
> CC: Krzysztof A. Sobiecki <sob...@gmail.com>
> CC: Steven Rostedt <rost...@goodmis.org>
> CC: Borislav Petkov <b...@alien8.de>
> CC: "H. Peter Anvin" <h...@zytor.com>
> CC: Andy Lutomirski <l...@amacapital.net>
> CC: Oleg Nesterov <o...@redhat.com>
> CC: Frederic Weisbecker <fweis...@gmail.com>
> CC: Alexei Starovoitov <a...@plumgrid.com>
> CC: Will Drewry <w...@chromium.org>
> CC: Kees Cook <keesc...@chromium.org>
> CC: x...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
