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