[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 12:04 PM, Al Viro <> 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

    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.


     \ /
      Last update: 2012-04-20 21:21    [W:0.021 / U:1.264 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site