[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120725082732.GZ9222@suse.de>
Date: Wed, 25 Jul 2012 09:27:32 +0100
From: Mel Gorman <mgorman@...e.de>
To: John David Anglin <dave.anglin@...l.net>
Cc: Fengguang Wu <fengguang.wu@...el.com>,
James Bottomley <James.Bottomley@...senPartnership.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
On Tue, Jul 24, 2012 at 05:08:04PM -0400, John David Anglin wrote:
> On 24-Jul-12, at 3:48 AM, Fengguang Wu wrote:
>
> >Here is the line in sock.i:
> >
> >struct static_key memalloc_socks = ((struct static_key) { .enabled
> >= ((atomic_t) { (0) }) });
>
>
> The above line contains two compound literals. It also uses a
> designated initializer
> to initialize the field enabled. A compound literal is not a
> constant expression.
>
> The location of the above statement isn't fully clear, but if a
> compound literal occurs
> outside the body of a function, the initializer list must consist of
> constant expressions.
>
> Removing "(atomic_t)" from the define results in a constant expression.
>
> Test case:
>
> typedef struct { long enabled; } atomic_t;
> struct static_key { atomic_t enabled; int x; };
> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> ((atomic_t) { (0) }) });
>
Thanks John for that explanation, it clears it up. The source of the
above line was linux-next/master:net/core/sock.c due to some patches I
merged. The exact line looks like this
struct static_key memalloc_socks = STATIC_KEY_INIT_FALSE;
and that thing in turns looks like
#define STATIC_KEY_INIT_FALSE ((struct static_key) \
{ .enabled = ATOMIC_INIT(0), .entries = (void *)0 })
This is a standard use of a static key (http://lwn.net/Articles/487426/)
and as I expect there will be more use of this feature in the future
it's good to get it fixed up first.
Thanks James for picking this up and putting a changelog on it.
--
Mel Gorman
SUSE Labs
--
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