Messages in this thread | | | Date | Fri, 20 Apr 2012 20:04:18 +0100 | From | Al Viro <> | Subject | Re: [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches) |
| |
On Fri, Apr 20, 2012 at 11:54:01AM -0700, Hugh Dickins wrote: > I can see that the discussion has since moved on quite a way from here. > > But it looks to me fairly easy for mm to stop doing fput() under mmap_sem. > > That's already the case when exiting (no mmap_sem held), and shouldn't add > observable cost when unmapping (we already work on a chain of vmas to be > freed, and when unmapping that chain will usually just be of one: shouldn't > matter to defer a final pass until after mmap_sem is dropped). Unless I'm > mistaken, the fput() buried in vma_adjust() can never be a final fput. > > Is it worth my trying to implement that? Or do you see an immediate > gotcha that I'm missing? Or are you happy enough with your deferred > fput() ideas, that it would be a waste of time to rearrange the mm end?
Deferring the final pass after dropping ->mmap_sem is going to be interesting; what would protect ->vm_next on those suckers? Locking rules are already bloody complicated in mm/*; this will only add more subtle fun. Note that right now both the dissolution of ->vm_next list and freeing of VMAs happen under ->mmap_sem; changing that might cost us a lot of headache...
| |