linux-kernel - Re: powerpc: introduce asm/swab.h

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]

Date:	Tue, 06 Jan 2009 22:02:28 -0800
From:	Harvey Harrison <harvey.harrison@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Nicolas Pitre <nico@....org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	David Miller <davem@...emloft.net>,
	David Howells <dhowells@...hat.com>
Subject: Re: powerpc: introduce asm/swab.h

On Tue, 2009-01-06 at 21:37 -0800, Linus Torvalds wrote:
> 
> On Wed, 7 Jan 2009, Nicolas Pitre wrote:
> 
> > On Tue, 6 Jan 2009, Linus Torvalds wrote:
> > > On Wed, 7 Jan 2009, Benjamin Herrenschmidt wrote:
> > > 
> > > Can you also verify that it works for you (not just compiles), just so 
> > > that I can commit it?
> > 
> > Tested OK on ARM (using LE mode with networking, etc.)
> 
> Ok, I committed it as a quick-fix. I'm not sure that is necessarily the 
> final one, but at least it is better than not compiling.

Yes, your fix should be all that is needed to fix it.  My apologies for not
rerunning all the compile tests (only did x86 but did a compile test with
x86 faking itself as a big endian arch)

> 
> For example, it's kind of silly to use two __fswab32()'s with other 
> oddness if that one just falls back on __constant_swab32: maybe we'd want 
> to make sure that we'd use ___constant_swab64() in that case, and only do 
> the whole __SWAB_64_THRU_32__ if we really have a __arch_swab32() 
> function.
> 
> Of course, I do hope that anybody who #defines __SWAB_64_THRU_32__ already 
> has that __arch_swab32() thing, so it's likely fine.

Hmm, this is a direct holdover from the old swab.h/swabb.h pieces.  I
came this close to eliminating that case too, but didn't have disassembly
to justify it.  You're right I think that changing that to:

#elif defined(__SWAB_64_THRU_32__) && defined(__arch_swab32)

makes a lot of sense, but I'd like to here from some arch guys.

The following arches define __SWAB_64_THRU_32__ and have __arch_swab32
arm, blackfin, avr32, cris, m68knommu, m68k, mips, sh, xtensa

And the following define __SWAB_64_THRU_32__ and don't have __arch_swab32
h8300
s390 (conditional on _ifndef __s390x__)
sparc (32-bit only)
frv
m32r
mn10300

Cheers,

Harvey


--
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/