From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Jones Subject: Re: Re: [PATCH 08/23] xen: statically initialize cpu_evtchn_mask_p Date: Wed, 09 Feb 2011 15:11:28 +0100 Message-ID: <4D52A090.6060003@redhat.com> References: <1286898271-32018-1-git-send-email-konrad.wilk@oracle.com> <1286898271-32018-9-git-send-email-konrad.wilk@oracle.com> <4D3DBA6A.3080700@redhat.com> <1295964137.14780.6148.camel@zakaz.uk.xensource.com> <4D5299D5.7080108@redhat.com> <1297260484.28185.43.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1297260484.28185.43.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 02/09/2011 03:08 PM, Ian Campbell wrote: > On Wed, 2011-02-09 at 13:42 +0000, Andrew Jones wrote: >> On 01/25/2011 03:02 PM, Ian Campbell wrote: >>> On Mon, 2011-01-24 at 17:44 +0000, Paolo Bonzini wrote: >>>> On 10/12/2010 05:44 PM, Konrad Rzeszutek Wilk wrote: >>>>> -static struct cpu_evtchn_s *cpu_evtchn_mask_p; >>>>> + >>>>> +static __initdata struct cpu_evtchn_s init_evtchn_mask = { >>>>> + .bits[0 ... (NR_EVENT_CHANNELS/BITS_PER_LONG)-1] = ~0ul, >>>>> +}; >>>>> +static struct cpu_evtchn_s *cpu_evtchn_mask_p =&init_evtchn_mask; >>>>> + >>>>> static inline unsigned long *cpu_evtchn_mask(int cpu) >>>>> { >>>>> return cpu_evtchn_mask_p[cpu].bits; >>>> >>>> This causes a modpost warning: >>>> >>>> WARNING: drivers/xen/built-in.o(.data+0x0): Section mismatch in >>>> reference from the variable cpu_evtchn_mask_p to the variable >>>> .init.data:init_evtchn_mask >>>> >>>> The variable cpu_evtchn_mask_p references >>>> the variable __initdata init_evtchn_mask >>>> >>>> If the reference is valid then annotate the >>>> variable with __init* or __refdata (see linux/init.h) or name the variable: >>>> *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, >>>> >>>> This is harmless, the variable is initialized to non-init data >>>> in an __init function. The added noise is ugly, though. >>> >>> Does this help? If I understand the comment which precedes __initref >>> correctly it is intended to address precisely this situation. >>> >>> Ian. >>> 8<--------- >>> >>> xen: events: mark cpu_evtchn_mask_p as __refdata >>> >>> This variable starts out pointing at init_evtchn_mask which is marked >>> __initdata but is set to point to a non-init data region in xen_init_IRQ >>> which is itself an __init function so this is safe. >>> >>> Signed-off-by: Ian Campbell >>> >>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c >>> index 31af0ac..5061af0 100644 >>> --- a/drivers/xen/events.c >>> +++ b/drivers/xen/events.c >>> @@ -114,7 +114,7 @@ struct cpu_evtchn_s { >>> static __initdata struct cpu_evtchn_s init_evtchn_mask = { >>> .bits[0 ... (NR_EVENT_CHANNELS/BITS_PER_LONG)-1] = ~0ul, >>> }; >>> -static struct cpu_evtchn_s *cpu_evtchn_mask_p = &init_evtchn_mask; >>> +static struct __refdata cpu_evtchn_s *cpu_evtchn_mask_p = >>> &init_evtchn_mask; >>> >>> static inline unsigned long *cpu_evtchn_mask(int cpu) >>> { >>> >> >> This does indeed fix it. Although you need __refdata to follow the >> complete struct name 'struct cpu_evtchn_s' rather than just 'struct', i.e. >> >> diff --git a/drivers/xen/events.c b/drivers/xen/events.c >> index 7468147..a313890 100644 >> --- a/drivers/xen/events.c >> +++ b/drivers/xen/events.c >> @@ -114,7 +114,7 @@ struct cpu_evtchn_s { >> static __initdata struct cpu_evtchn_s init_evtchn_mask = { >> .bits[0 ... (NR_EVENT_CHANNELS/BITS_PER_LONG)-1] = ~0ul, >> }; >> -static struct cpu_evtchn_s *cpu_evtchn_mask_p = &init_evtchn_mask; >> +static struct cpu_evtchn_s __refdata *cpu_evtchn_mask_p = >> &init_evtchn_mask; >> >> static inline unsigned long *cpu_evtchn_mask(int cpu) >> { >> >> >> Ian, are you going to push this to lkml in one of your batches? > > Sure. > > Can I add an Acked- and/or Tested-by from you? > Sure. Either-or or both. I ack it and have tested it. Drew