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: <1231308148.14442.17.camel@brick>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ