lkml.org 
[lkml]   [2015]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: can't oom-kill zap the victim's memory?
    From
    Date
    On 09/19/15 15:24, Linus Torvalds wrote:
    > On Sat, Sep 19, 2015 at 8:03 AM, Oleg Nesterov <oleg@redhat.com> wrote:
    >> +
    >> +static void oom_unmap_func(struct work_struct *work)
    >> +{
    >> + struct mm_struct *mm = xchg(&oom_unmap_mm, NULL);
    >> +
    >> + if (!atomic_inc_not_zero(&mm->mm_users))
    >> + return;
    >> +
    >> + // If this is not safe we can do use_mm() + unuse_mm()
    >> + down_read(&mm->mmap_sem);
    > I don't think this is safe.
    >
    > What makes you sure that we might not deadlock on the mmap_sem here?
    > For all we know, the process that is going out of memory is in the
    > middle of a mmap(), and already holds the mmap_sem for writing. No?

    Potentially stupid question that others may be asking: Is it legal to
    return EINTR from mmap() to let a SIGKILL from the OOM handler punch the
    task out of the kernel and back to userspace?

    (sorry for the dupe btw, new email client snuck in html and I got bounced)

    > So at the very least that needs to be a trylock, I think. And I'm not
    > sure zap_page_range() is ok with the mmap_sem only held for reading.
    > Normally our rule is that you can *populate* the page tables
    > concurrently, but you can't tear the down.
    >
    > Linus
    >
    > --
    > To unsubscribe, send a message with 'unsubscribe linux-mm' in
    > the body to majordomo@kvack.org. For more info on Linux MM,
    > see: http://www.linux-mm.org/ .
    > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>



    \
     
     \ /
      Last update: 2015-09-20 01:21    [W:4.066 / U:0.728 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site