Re: [Xen-devel] Xen 4.6.0-rc1 build with lock_profile=y crash_debug=y, frame_pointer=y and domain.c:241: error: negative width in bit-field â<anonymous>â

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 25/08/15 18:09, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 25, 2015 at 05:48:58PM +0100, Andrew Cooper wrote:
>> On 25/08/15 17:43, Konrad Rzeszutek Wilk wrote:
>>> I am troubleshooting an locking issue and figured I would enable extra 
>>> options.
>>>
>>> But now I am hitting this build issue:
>>>
>>> domain.c:241: error: negative width in bit-field â<anonymous>â
>>>
>>> Which is:
>>>
>>>  229 struct domain *alloc_domain_struct(void)
>>>  230 {
>>>  231     struct domain *d;
>>> ...
>>>  241     BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>>>
>>> Thoughts?
>> That is to catch the case where sizeof struct domain exceeds PAGE_SIZE.
>>
>> The logic behind this was to prevent needing order 1 allocations for
>> domains or vcpus, and therefore allocation failures in heavily memory
>> fragmented situations.
>>
>> It means we will probably need to find some other areas of struct domain
>> to shrink, or move out into a separate xmalloc().
>>
>> For straight debugging, it is acceptable to drop the BUILD_BUG_ON().  If
>> we can't drop the size of struct domain, we might want to move to using
>> vmalloc() instead.
> It is big. pahole says:
>
>    /* size: 4352, cachelines: 68, members: 74 */ 
>     /* sum members: 4238, holes: 9, sum holes: 34 */ 
>     /* padding: 80 */ 
>     /* paddings: 1, sum paddings: 4 */

So by rearranging to reduce padding, it would easily fit ;p

>
> Would this patch be OK then:
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 045f6ff..cc9ce0b 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -238,7 +238,9 @@ struct domain *alloc_domain_struct(void)
>      if ( unlikely(!bits) )
>           bits = _domain_struct_bits();
>  
> +#ifndef LOCK_PROFILE
>      BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> +#endif
>      d = alloc_xenheap_pages(0, MEMF_bits(bits));
>      if ( d != NULL )
>          clear_page(d);
>
> (not compile tested nor runtime tested)

Either remove it locally for debugging, or use something like

#if sizeof(*d) <= PAGE_SIZE
... alloc_xenheap_pages(0, MEMF_bits(bits));
#else
... vzalloc(sizeof(*d), ...);
#endif

Although this would require passing memflags to the v?alloc()
infrastructure.

Jan: While reading the code, I note that the bits restriction is not
required if CONFIG_BIGMEM, and should probably become conditional.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel