lkml.org 
[lkml]   [2012]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches)
    On Fri, 20 Apr 2012, Linus Torvalds wrote:
    > On Fri, Apr 20, 2012 at 12:04 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
    > >
    > > Deferring the final pass after dropping ->mmap_sem is going to be
    > > interesting; what would protect ->vm_next on those suckers?
    >
    > Just remove them from the active list, and keep them linked to each
    > other using vm_next.
    >
    > After all, the only case we care about is the case where the vma gets
    > removed entirely, so we just put them on their own list.
    >
    > In fact, that's what we already do for other reasons. See
    > detach_vmas_to_be_unmapped().
    >
    > So vm_next is actually entirely *private* by this time, and needs no
    > locking at all.
    >
    > As far as I can tell, we could just make do_munmap() return that
    > private list, and then do the fput's and freeing of the list outside
    > the mmap_sem lock.
    >
    > That actually looks pretty simple. There are a fair number of callers,
    > which looks to be the main annoyance. But fixing it up with some
    > pattern of "do finish_munmap after drooping the mmap_sem" doesn't look
    > *complicated*, just slightly annoying.
    >
    > The *bigger* annoyance is actually "do_mmap()", which does a
    > do_munmap() as part of it, so it needs the same cleanup too.
    >
    > There might be other cases that do munmap as part of their operation
    > (and that have the mmap_sem held outside of the caller), but
    > do_munmap() and do_mmap() seem to be the two obvious ones.
    >
    > Many of the callers seem to do the mmap_sem() right around the call,
    > though (see binfmt_elf.c for example), so it really would be a rather
    > local fixup.

    Yes, that's exactly how I was thinking of it.

    Hugh


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