On (01/18/16 16:11), Minchan Kim wrote: [..] > > so, even if clear_bit_unlock/test_and_set_bit_lock do smp_mb or > > barrier(), there is no corresponding barrier from record_obj()->WRITE_ONCE(). > > so I don't think WRITE_ONCE() will help the compiler, or am I missing > > something? > > We need two things thanks. > 1. compiler barrier um... probably gcc can reorder that sequence to something like this *handle = obj_malloc() /* unpin the object */ zs_object_copy(*handle, used_obj, class) /* now use it*/ ok. > 2. memory barrier. > > As compiler barrier, WRITE_ONCE works to prevent store tearing here > by compiler. > However, if we omit unpin_tag here, we lose memory barrier(e,g, smp_mb) > so another CPU could see stale data caused CPU memory reordering. oh... good find! lost release semantic of unpin_tag()... -ss -- 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>