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] [day] [month] [year] [list]
Date:	Fri, 14 Nov 2008 08:33:45 -0800
From:	Harvey Harrison <harvey.harrison@...il.com>
To:	Piet Delaney <piet.delaney@...silica.com>
Cc:	Chris Zankel <chris@...kel.net>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Marc Gauthier <marc@...silica.com>,
	Joe Taylor <joetayloremail@...il.com>,
	linux-xtensa@...ux-xtensa.org, Chuck Lever <chuck.lever@...cle.com>
Subject: Re: [PATCH 10/10] xtensa: use the new byteorder headers - Merged
 with your previous xtensa-next and will remerge shortly.

On Fri, 2008-11-14 at 00:13 -0800, Piet Delaney wrote:
> Piet Delaney wrote:
> > Harvey Harrison wrote:
> >> On Fri, 2008-11-07 at 19:00 -0800, Piet Delaney wrote:
> >>> Hi Chris:
> >>>
> >>>    I've merged your recent xtensa-next with our 2.6.24-smp repo.
> >>> It seems to work fine and I'm in the process of cleaning it
> >>> up a bit and adding preliminary XTENSA kgdb support.
> >>
> >> 2.6.24?  In that case you probably don't have include/linux/byteorder.h,
> >> or include/linux/swab.h which would explain your byteorder problems.
> >>
> >> Or is that a typo in the version numbers?
> > 
> > I was on 2.6.24 and didn't have a problem compiling the kernel -O0 other
> > than a minor tweak in slab.c. Now in 2.6.27-rc3 I get a compile problem
> > with rpcb_clnt.c at lines 122, 123, and 129:
> > 
> >    /export/src/xtensa-next/net/sunrpc/rpcb_clnt.c:129: error: (near 
> > initialization for 'rpcb_in6addr_loopback.sin6_port')
> > 
> 
> The problem is fixed by changing htons() to __constant_htons().
> The __constant_*() flavors use a #define and always compile
> to a constant. Ex:
> 
> #define ___constant_swab32(x) \
>          ((__u32)( \
>                  (((__u32)(x) & (__u32)0x000000ffUL) << 24) | \
>                  (((__u32)(x) & (__u32)0x0000ff00UL) <<  8) | \
>                  (((__u32)(x) & (__u32)0x00ff0000UL) >>  8) | \
>                  (((__u32)(x) & (__u32)0xff000000UL) >> 24) ))
> 
> I tried compiling the recent snapshot from Linus's tree and it
> has a new instance of the problem in a common network file.
> 
> In this case the recent change was FROM __constant_htons()
> to htons(). See net/core/dev.c`simple_tx_hash():

I find it strange that the net/core/dev.c bits of this commit were
a problem as they were only changing the use inside the case: statements
which had to be constants in the first place and had better be picked
up by the __builtin_constant_p inside swab32().

I believe you said you were compiling at -O0?  What compiler?

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