On Tue, Aug 20, 2019 at 11:12:10AM +1000, Dave Chinner wrote: > On Mon, Aug 19, 2019 at 09:38:41AM -0300, Jason Gunthorpe wrote: > > On Mon, Aug 19, 2019 at 07:24:09PM +1000, Dave Chinner wrote: > > > > > So that leaves just the normal close() syscall exit case, where the > > > application has full control of the order in which resources are > > > released. We've already established that we can block in this > > > context. Blocking in an interruptible state will allow fatal signal > > > delivery to wake us, and then we fall into the > > > fatal_signal_pending() case if we get a SIGKILL while blocking. > > > > The major problem with RDMA is that it doesn't always wait on close() for > > the > > MR holding the page pins to be destoyed. This is done to avoid a > > deadlock of the form: > > > > uverbs_destroy_ufile_hw() > > mutex_lock() > > [..] > > mmput() > > exit_mmap() > > remove_vma() > > fput(); > > file_operations->release() > > I think this is wrong, and I'm pretty sure it's an example of why > the final __fput() call is moved out of line.
Yes, I think so too, all I can say is this *used* to happen, as we have special code avoiding it, which is the code that is messing up Ira's lifetime model. Ira, you could try unraveling the special locking, that solves your lifetime issues? Jason
