Re: reproducible panic in netisr

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Mon, 10 Aug 2009 19:02:10 +0100 (BST)
On Mon, 10 Aug 2009, Julian Elischer wrote:

>> One possible workaround would be to force the __start_ symbol and the 
>> section to be equally aligned and thus on the same address using linker 
>> scripts.  The drawbacks are that we need to touch the fragile linker 
>> scripts for each of the sections we add and for all architectures 
>> individually.  As the enforcement of alignment would be at a different 
>> place to the actual set creation, putting the alignment in might be easily 
>> forgotten.
>
> personally I'd see if there is a way to align the section on a page 
> boundary..

I'm not sure it matters for the master copy, but I believe some (if not all) 
architecture MD parts already allocate the per-CPU data areas as page-aligned, 
and we extend the master copy out to a page boundary.  That said, it would be 
worth checking on a run-time kernel to make sure it works out that way in 
practice.  In the future, we'll want the pages allocated to the DPCPU area to 
be local to the CPU from a NUMA perspective.

>> --- sys/net/vnet.h    (revision 196086)
>> +++ sys/net/vnet.h    (working copy)
>> _at__at_ -185,12 +185,14 _at__at_
>>   * Virtual network stack memory allocator, which allows global variables 
>> to
>>   * be automatically instantiated for each network stack instance.
>>   */
>> +__asm__(
>>  #if defined(__arm__)
>> -__asm__(".section " VNET_SETNAME ", \"aw\", %progbits");
>> +    ".section " VNET_SETNAME ", \"aw\", %progbits\n"
>>  #else
>> -__asm__(".section " VNET_SETNAME ", \"aw\", _at_progbits");
>> +    ".section " VNET_SETNAME ", \"aw\", _at_progbits\n"
>>  #endif
>
> I may be visually impaired but I'm not seeing a reason for the ifdef arm..

I stared at Jeff's original DPCPU code for a while before I saw it -- it's the 
"%" vs "_at_" difference.

Robert N M Watson
Computer Laboratory
University of Cambridge
Received on Mon Aug 10 2009 - 16:02:11 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:53 UTC