On Thu, Sep 06, 2018 at 08:29:28AM +0300, Leon Romanovsky wrote: > On Wed, Sep 05, 2018 at 05:21:37PM -0600, Jason Gunthorpe wrote: > > On Tue, Sep 04, 2018 at 03:12:28PM +0300, Leon Romanovsky wrote: > > > After releasing ucontext the __mmu_notifier_release will be called > > > again in exit_mmap path. However at that time the driver ucontext > > > (mlx5_ib_ucontext) already will be freed and it will cause > > > to use-after-free error, due to improper use of mmu_notifier API. > > > > I can't see how this fix is right, it needs more explanation if it is. > > > > The way it is supposed to work is that the umem *CANNOT* outlive the > > ucontext. > > mmu_notifier operates on ib_context and not on umem and my > fix/analysis umem links a mm_struct to a ib_ucontext. The ownership of that link is the umem object, and when the umem is destroyed that link goes away. The umem object itself doesn't contribute any memory to the linking though. > > ie owning_mm == NULL, which skipped the unregister.. Leaving a > > dangling hlist reference in the mm if it hasn't already been cleaned > > up by something else. > > AFAIR, I tried to add prints before "goto out_put_task;" > and saw nothing, I'll recheck. It is probably a leaking umem then.. Add a counter of created/destroyed umems and verify it is zero at ucontext destruction to look for leaking umem. This would be a good functionality to have in the kernel anyhow... Jason
