linux-kernel - Re: [PATCH] x86: Simple changes to make traps_32.c and traps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080701195004.GA27557@elte.hu>
Date:	Tue, 1 Jul 2008 21:50:04 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alexander van Heukelum <heukelum@...lshack.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: Simple changes to make traps_32.c and traps_64.c
	more similar


* Alexander van Heukelum <heukelum@...lshack.com> wrote:

> Tiny first step at unification of traps_32.c and traps_64.c. All
> changes are meant to be trivial.
>  - mostly whitespace changes
>  - chose one of obviously equivalent pieces of code:
> 	 - reordering of declarations
> 	 - simple renaming of local variables
> 	 - if (cond) { ... } -> if (!cond) goto end_of_block ...
> 	 - local caching of current, cpu, etc...
> 
> This makes the diff between traps_32.c and traps_64.c smaller:
> 
> from:
>   1474  +++++++++++++++++++++++++++++--------------------------------
>   1 file changed, 722 insertions(+), 752 deletions(-)
>   
> to:
>   1052  +++++++++++++++++++++++++++++--------------------------------
>   1 file changed, 512 insertions(+), 540 deletions(-)

nice. In terms of functionality, it is supposed to be a pure 
no-changes-intended commit, correct?

In that case it makes sense to split it in two: in the first (larger) 
bit put the things that are provably invariant on the .o and can be 
verified that way.

In the second one, put the things that change the .o output slightly 
(variable reordering can do that) - this we have to check more closely.

(One can normally do such a splitup by editing the raw diff and 
splitting it in half that way - by sorting each chunk into the 
appropriate target patch - and then making sure the end result is still 
the same.)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/