linux-kernel - Re: [PATCH] xz: make use of BCJ filter also for 32-bit x86 kernel

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: <20120319143647.3cf46ed2@tukaani.org>
Date:	Mon, 19 Mar 2012 14:36:47 +0200
From:	Lasse Collin <lasse.collin@...aani.org>
To:	"Jan Beulich" <JBeulich@...e.com>
Cc:	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] xz: make use of BCJ filter also for 32-bit x86 kernel

On 2012-03-19 Jan Beulich wrote:
> >>> On 16.03.12 at 19:47, Lasse Collin <lasse.collin@...aani.org>
> >>> wrote:
> > On 2012-03-15 Jan Beulich wrote:
> >> The ARCH value for 32-bit x86 is not x86, but i?86.
> > 
> > Thanks for noticing this. Is ARCH even the correct variable to use?
> > Maybe SRCARCH would be better. Then it would be enough to test for
> > x86, if I understand the toplevel Makefile correctly.
> 
> Yes, that might be even better (albeit requiring adjustment of the
> script should the naming in the source tree ever change again,
> whereas the ARCH values are supposedly stable).

I think I will go with SRCARCH then. The directory names don't change so
often.

Could you quickly check if the following is OK? It works on x86-64.

diff --git a/scripts/xz_wrap.sh b/scripts/xz_wrap.sh
--- a/scripts/xz_wrap.sh
+++ b/scripts/xz_wrap.sh
@@ -12,8 +12,8 @@
 BCJ=
 LZMA2OPTS=
 
-case $ARCH in
-	x86|x86_64)     BCJ=--x86 ;;
+case $SRCARCH in
+	x86)            BCJ=--x86 ;;
 	powerpc)        BCJ=--powerpc ;;
 	ia64)           BCJ=--ia64; LZMA2OPTS=pb=4 ;;
 	arm)            BCJ=--arm ;;

> Will you get a patch to Linus then to fix all of these in 3.4?

I will. Should the fix be included in the stable trees too? I'm not sure
if this is acceptable under the stable kernel rules. At least someone
should test it on SPARC first.

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode
--
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/