lkml.org 
[lkml]   [2017]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm, oom: fix potential data corruption when oom_reaper races with writer
On Fri 04-08-17 19:41:42, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Fri 04-08-17 17:25:46, Tetsuo Handa wrote:
> > > Well, while lockdep warning is gone, this problem is remaining.
> > >
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index edabf6f..1e06c29 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -3931,15 +3931,14 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
> > > /*
> > > * This mm has been already reaped by the oom reaper and so the
> > > * refault cannot be trusted in general. Anonymous refaults would
> > > - * lose data and give a zero page instead e.g. This is especially
> > > - * problem for use_mm() because regular tasks will just die and
> > > - * the corrupted data will not be visible anywhere while kthread
> > > - * will outlive the oom victim and potentially propagate the date
> > > - * further.
> > > + * lose data and give a zero page instead e.g.
> > > */
> > > - if (unlikely((current->flags & PF_KTHREAD) && !(ret & VM_FAULT_ERROR)
> > > - && test_bit(MMF_UNSTABLE, &vma->vm_mm->flags)))
> > > + if (unlikely(!(ret & VM_FAULT_ERROR)
> > > + && test_bit(MMF_UNSTABLE, &vma->vm_mm->flags))) {
> > > + if (ret & VM_FAULT_RETRY)
> > > + down_read(&vma->vm_mm->mmap_sem);
> > > ret = VM_FAULT_SIGBUS;
> > > + }
> > >
> > > return ret;
> > > }
> >
> > I have re-read your email again and I guess I misread previously. Are
> > you saying that the data corruption happens with the both patches
> > applied?
>
> Yes. Data corruption still happens.

I guess I managed to reproduce finally. Will investigate further.

Thanks!
--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2017-08-04 13:01    [W:0.065 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site