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:	Mon, 23 Jul 2012 12:20:20 +0100
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Mel Gorman <mgorman@...e.de>
Cc:	Fengguang Wu <fengguang.wu@...el.com>,
	kernel-janitors@...r.kernel.org,
	Kyle McMartin <kyle@...isc-linux.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Parisc List <linux-parisc@...r.kernel.org>
Subject: Re: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer
 element is not constant

[Parisc list cc added]
On Mon, 2012-07-23 at 12:16 +0100, Mel Gorman wrote:
> On Mon, Jul 23, 2012 at 12:30:58AM +0800, Fengguang Wu wrote:
> > Hi Mel,
> > 
> > To be frank, I don't quite understand this build failure..
> > 
> > tree:   next/akpm akpm
> > head:   37e2ad4953983527f7bdb6831bf478eedcc84082
> > commit: 799dc3a908b1df8b766c35aefc24c1b5356aa051 [129/309] netvm: allow skb allocation to use PFMEMALLOC reserves
> > config: parisc-defconfig (attached as .config)
> > 
> > All related error/warning messages:
> > 
> > net/core/sock.c:274:36: error: initializer element is not constant
> > net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
> > net/core/sock.c:274:36: error: initializer element is not constant
> > 
> 
> It looks parisc specific so am adding some parisc because this builds but
> I am less sure if it is actually correct. If it's correct, it should be
> appear before the swap-over-nfs patches to avoid bisection problems.
> I've added some parisc folk for review.
> 
> ---8<---
> parisc: Redefine ATOMIC_INIT and ATOMIC64_INIT like other architectures
> 
> The following build error occured during a parisc build with
> swap-over-NFS patches applied.
> 
> net/core/sock.c:274:36: error: initializer element is not constant
> net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
> net/core/sock.c:274:36: error: initializer element is not constant
> 
> It's not obvious but this is due to how ATOMIC_INIT is defined on
> parisc. It should affect any user of STATIC_KEY_INIT_FALSE on that
> platform.
> 
> This patch makes the definition of ATOMIC_INIT on parisc to look like
> other arches definition.
> 
> Reported-by: Fengguang Wu <fengguang.wu@...el.com>
> Signed-off-by: Mel Gorman <mgorman@...e.de>
> ---
>  arch/parisc/include/asm/atomic.h |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
> index 6c6defc..af9cf30 100644
> --- a/arch/parisc/include/asm/atomic.h
> +++ b/arch/parisc/include/asm/atomic.h
> @@ -141,7 +141,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
>  
>  #define atomic_sub_and_test(i,v)	(atomic_sub_return((i),(v)) == 0)
>  
> -#define ATOMIC_INIT(i)	((atomic_t) { (i) })
> +#define ATOMIC_INIT(i)	{ (i) }
>  
>  #define smp_mb__before_atomic_dec()	smp_mb()
>  #define smp_mb__after_atomic_dec()	smp_mb()
> @@ -150,7 +150,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int a, int u)
>  
>  #ifdef CONFIG_64BIT
>  
> -#define ATOMIC64_INIT(i) ((atomic64_t) { (i) })
> +#define ATOMIC64_INIT(i) { (i) }
>  
>  static __inline__ s64
>  __atomic64_add_return(s64 i, atomic64_t *v)

OK, I don't understand this either ... why would not casting to the
appropriate type suddenly stop warning about the initialiser being non
constant.  It looks like some type of gcc bug to me.  Our toolchain
expert (Dave) hangs out on the parisc list ... he'll want to know your
gcc -v.

James


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