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

Re: [Xen-devel] [PATCH 2/3] xmalloc: don't evaluate ADD_REGION without holding the pool lock



> -----Original Message-----
> From: Jan Beulich <JBeulich@xxxxxxxx>
> Sent: 03 July 2019 10:57
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Julien Grall <julien.grall@xxxxxxx>; 
> Andrew Cooper
> <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap <George.Dunlap@xxxxxxxxxx>; Ian 
> Jackson
> <Ian.Jackson@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; Konrad 
> Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx>; Tim (Xen.org) <tim@xxxxxxx>; Wei Liu <wl@xxxxxxx>
> Subject: Re: [PATCH 2/3] xmalloc: don't evaluate ADD_REGION without holding 
> the pool lock
> 
> On 02.07.2019 18:38, Paul Durrant wrote:
> > --- a/xen/common/xmalloc_tlsf.c
> > +++ b/xen/common/xmalloc_tlsf.c
> > @@ -380,18 +380,22 @@ void *xmem_pool_alloc(unsigned long size, struct 
> > xmem_pool *pool)
> >      int fl, sl;
> >      unsigned long tmp_size;
> >
> > +    spin_lock(&pool->lock);
> >      if ( pool->init_region == NULL )
> >      {
> > +       spin_unlock(&pool->lock);
> >         if ( (region = pool->get_mem(pool->init_size)) == NULL )
> >             goto out;
> > +       spin_lock(&pool->lock);
> >         ADD_REGION(region, pool->init_size, pool);
> > -       pool->init_region = region;
> > +       /* Re-check since the lock was dropped */
> > +       if ( pool->init_region == NULL )
> > +           pool->init_region = region;
> >      }
> 
> Instead of this, how about deleting the init_region field?
> It's not really used anywhere. I'm not going to exclude that
> functions like FIND_SUITABLE_BLOCK() expect _some_ region to
> be there in the pool, but that still wouldn't require
> tracking which one was the first to get allocated. A check
> like that in xmem_pool_destroy() would then do here to make
> sure at least one region is there.
> 

Ok, I can do it that way instead... not that anything calls xmem_pool_destroy 
at the moment anyway.

  Paul

> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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