On Thu, Aug 22, 2019 at 10:42:39AM +0200, Daniel Vetter wrote: > > RDMA has a mutex: > > > > ib_umem_notifier_invalidate_range_end > > rbt_ib_umem_for_each_in_range > > invalidate_range_start_trampoline > > ib_umem_notifier_end_account > > mutex_lock(&umem_odp->umem_mutex); > > > > I'm working to delete this path though! > > > > nonblocking or not follows the start, the same flag gets placed into > > the mmu_notifier_range struct passed to end. > > Ok, makes sense. > > I guess that also means the might_sleep (I started on that) in > invalidate_range_end also needs to be conditional? Or not bother with > a might_sleep in invalidate_range_end since you're working on removing > the last sleep in there? I might suggest the same pattern as used for locked, the might_sleep unconditionally on the start, and a 2nd might sleep after the IF in __mmu_notifier_invalidate_range_end() Observing that by audit all the callers already have the same locking context for start/end Jason _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel