> > Shouldn't that be enforced with READ_ONCE() then? Yep, I can add that.
> Good point, although I think the acquire_* function itself may be called > from a higher layer with the mmap_sem always held. I wonder if we need > barriers around get and put mmio_atsd_reg. test_and_set_bit() should imply a memory barrier so I don't think we need one there (and looking at the implementation there is one). clear_bit() might need one though. For that I guess I could use clear_bit_unlock()? There is also a matching test_and_set_bit_lock() so I will submit a v2 which uses those instead given we are using these like a lock. > > > I don't think we can as the invalidate_range() function is called under > > > the ptl > > > spin-lock and is not allowed to sleep (at least according to > > > include/linux/mmu_notifier.h). > > I double checked, It's the reverse > > /* > * If both of these callbacks cannot block, mmu_notifier_ops.flags > * should have MMU_INVALIDATE_DOES_NOT_BLOCK set. > */ Argh, that must have been merged during the current window. Thanks for pointing out - I will submit a seperate patch to update the mmu_notifier_ops.flags to set MMU_INVALIDATE_DOES_NOT_BLOCK. - Alistair > void (*invalidate_range_start)(struct mmu_notifier *mn, > struct mm_struct *mm, > unsigned long start, unsigned long > end); > void (*invalidate_range_end)(struct mmu_notifier *mn, > struct mm_struct *mm, > unsigned long start, unsigned long end); > > > > > > - Alistair > > > > > > > Balbir > > > > > > > > > > > > > > > I think it looks good to me otherwise, > > Balbir Singh. >