On Wed, 2 Sep 2015 13:04:08 -0500 (CDT) Christoph Lameter <cl@xxxxxxxxx> wrote: > On Wed, 2 Sep 2015, Jesper Dangaard Brouer wrote: > > > > +error: > > > + __kmem_cache_free_bulk(s, i, p); > > > > Don't we need to update "tid" here, like: > > > > c->tid = next_tid(c->tid); > > > > Consider a call to the ordinary kmem_cache_alloc/slab_alloc_node was > > in-progress, which get PREEMPT'ed just before it's call to > > this_cpu_cmpxchg_double(). > > Now, this function gets called and we modify c->freelist, but cannot > > get all objects and then fail (goto error). Although we put-back > > objects (via __kmem_cache_free_bulk) don't we want to update c->tid > > in-order to make sure the call to this_cpu_cmpxchg_double() retry? > > Hmm... I thought that __kmem_cache_free_bulk is run with interrupts > disabled and will invoke the __slab_free which will increment tid if any > objects are freed from the local page. Ah, yes. Fallback __kmem_cache_free_bulk() will invoke slab_free(), which will have updated c->tid. The patch is correct. -- Best regards, Jesper Dangaard Brouer MSc.CS, Sr. Network Kernel Developer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>