[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Tue, Aug 25, 2015 at 03:52:15PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 25, 2015 at 06:41:06PM +0100, Andrew Cooper wrote:
> > 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

I forgot to mention that by removing it locally Xen ends up halting at:

(XEN) Detected 3292.657 MHz processor.

..

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.