[PATCH hmm 02/15] mm/mmu_notifier: add an interval tree notifier

Jason Gunthorpe jgg at mellanox.com
Mon Oct 21 19:24:53 UTC 2019


On Mon, Oct 21, 2019 at 03:11:57PM -0400, Jerome Glisse wrote:
> > Since that reader is not locked we need release semantics here to
> > ensure the unlocked reader sees a fully initinalized mmu_notifier_mm
> > structure when it observes the pointer.
> 
> I thought the mm_take_all_locks() would have had a barrier and thus
> that you could not see mmu_notifier struct partialy initialized. 

Not sure, usually a lock acquire doesn't have a store barrier?

Even if it did, we would still need some pairing read barrier..

> having the acquire/release as safety net does not hurt. Maybe add a
> comment about the struct initialization needing to be visible before
> pointer is set.

Is this clear?

         * release semantics on the initialization of the
         * mmu_notifier_mm's contents are provided for unlocked readers.
	 * acquire can only be used while holding the
         * mmgrab or mmget, and is safe because once created the
         * mmu_notififer_mm is not freed until the mm is destroyed.
         * Users holding the mmap_sem or one of the
	 * mm_take_all_locks() do not need to use acquire semantics.

It also helps explain why there is no locking around the other
readers, which has puzzled me in the past at least.

Jason


More information about the amd-gfx mailing list