[lkml]   [2012]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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...

     \ /
      Last update: 2012-04-20 21:07    [W:0.023 / U:0.840 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site