On Wed, May 9, 2012 at 10:25 AM, Christoph Lameter <cl@xxxxxxxxx> wrote: > On Wed, 9 May 2012, Pravin Shelar wrote: > >> On Tue, May 8, 2012 at 12:22 PM, Christoph Lameter <cl@xxxxxxxxx> wrote: >> > On Tue, 8 May 2012, Eric Dumazet wrote: >> > >> >> On Tue, 2012-05-08 at 11:55 -0700, Pravin B Shelar wrote: >> >> > Transparent huge pages can change page->flags (PG_compound_lock) >> >> > without taking Slab lock. So sl[auo]b need to use atomic bit >> >> > operation while changing page->flags. >> >> > Specificly this patch fixes race between compound_unlock and slab >> >> > functions which does page-flags update. This can occur when >> >> > get_page/put_page is called on page from slab object. >> >> >> >> >> >> But should get_page()/put_page() be called on a page own by slub ? >> > >> > Can occur in slab allocators if the slab memory is used for DMA. I dont >> > like the performance impact of the atomics. In particular slab_unlock() in >> > slub is or used to be a hot path item. It is still hot on arches that do >> > not support this_cpu_cmpxchg_double. With the cmpxchg_double only the >> > debug mode is affected. >> > >> >> I agree this would impact performance. I am not sure how else we can >> fix this issue. As far as slab_unlock in hot path case is concerned, >> it is more likely to corrupt page->flags in that case. > > Dont modify any page flags from THP logic if its a slab page? THP cannot > break up or merge slab pages anyways. Good idea, I will post patch soon. > > -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>