WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH 08/23] xen: statically initialize cpu_evtchn_

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 08/23] xen: statically initialize cpu_evtchn_mask_p
From: Andrew Jones <drjones@xxxxxxxxxx>
Date: Wed, 09 Feb 2011 15:11:28 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 09 Feb 2011 06:12:05 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1297260484.28185.43.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1286898271-32018-1-git-send-email-konrad.wilk@xxxxxxxxxx> <1286898271-32018-9-git-send-email-konrad.wilk@xxxxxxxxxx> <4D3DBA6A.3080700@xxxxxxxxxx> <1295964137.14780.6148.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D5299D5.7080108@xxxxxxxxxx> <1297260484.28185.43.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100827 Red Hat/3.1.3-1.el6 Lightning/1.0b2 Thunderbird/3.1.3
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 <ian.campbell@xxxxxxxxxx>
>>>
>>> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>