lkml.org 
[lkml]   [2017]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/2] mm, oom: fix potential data corruption when oom_reaper races with writer
    On Thu 10-08-17 10:21:18, Michal Hocko wrote:
    > On Tue 08-08-17 19:48:55, Andrea Arcangeli wrote:
    > [...]
    > > The bug corrected by this patch 1/2 I pointed it out last week while
    > > reviewing other oom reaper fixes so that looks fine.
    > >
    > > However I'd prefer to dump MMF_UNSTABLE for good instead of adding
    > > more of it. It can be replaced with unmap_page_range in
    > > __oom_reap_task_mm with a function that arms a special migration entry
    > > so that no branchs are added to the fast paths and it's all hidden
    > > inside is_migration_entry slow paths.
    >
    > This sounds like an interesting idea but I would like to address the
    > _correctness_ issue first and optimize on top of it. If for nothing else
    > backporting a follow up fix sounds easier than a complete rework. There
    > are quite some callers of is_migration_entry and the patch won't be
    > trivial either. So can we focus on the fix first please?

    Btw, if the overhead is a concern then we can add a jump label and only
    make the code active only while the OOM is in progress. We already do
    count all oom victims so we have a clear entry and exit points. This
    would still sound easier to do than teach every is_migration_entry a new
    migration entry type and handle it properly, not to mention make
    everybody aware of this for future callers of is_migration_entry.
    --
    Michal Hocko
    SUSE Labs

    \
     
     \ /
      Last update: 2017-08-10 15:34    [W:3.796 / U:0.632 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site