Messages in this thread | | | Date | Sun, 20 Sep 2015 11:33:33 +0200 | From | Michal Hocko <> | Subject | Re: can't oom-kill zap the victim's memory? |
| |
On Sat 19-09-15 15:24:02, 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? > > So at the very least that needs to be a trylock, I think.
Agreed.
> 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
Actually mmap_sem for reading should be sufficient because we do not alter the layout. Both MADV_DONTNEED and MADV_FREE require read mmap_sem for example.
-- Michal Hocko SUSE Labs
| |