Re: [PATCH v2] mm/memory.c: do_fault: avoid usage of stale vm_area_struct

2019-03-02 Thread Jan Stancek
- Original Message - > Hello Jan, > > On Sat, Mar 02, 2019 at 07:19:39PM +0100, Jan Stancek wrote: > > + struct mm_struct *vm_mm = READ_ONCE(vma->vm_mm); > > The vma->vm_mm cannot change under gcc there, so no need of > READ_ONCE. The release of mmap_sem has release semantics so the

Re: [PATCH v2] mm/memory.c: do_fault: avoid usage of stale vm_area_struct

2019-03-02 Thread Andrea Arcangeli
Hello Jan, On Sat, Mar 02, 2019 at 07:19:39PM +0100, Jan Stancek wrote: > + struct mm_struct *vm_mm = READ_ONCE(vma->vm_mm); The vma->vm_mm cannot change under gcc there, so no need of READ_ONCE. The release of mmap_sem has release semantics so the vma->vm_mm access cannot be reordered after

Re: [PATCH v2] mm/memory.c: do_fault: avoid usage of stale vm_area_struct

2019-03-02 Thread Peter Zijlstra
On Sat, Mar 02, 2019 at 07:19:39PM +0100, Jan Stancek wrote: > static vm_fault_t do_fault(struct vm_fault *vmf) > { > struct vm_area_struct *vma = vmf->vma; > + struct mm_struct *vm_mm = READ_ONCE(vma->vm_mm); Would this not need a corresponding WRITE_ONCE() in vma_init() ?

[PATCH v2] mm/memory.c: do_fault: avoid usage of stale vm_area_struct

2019-03-02 Thread Jan Stancek
LTP testcase mtest06 [1] can trigger a crash on s390x running 5.0.0-rc8. This is a stress test, where one thread mmaps/writes/munmaps memory area and other thread is trying to read from it: CPU: 0 PID: 2611 Comm: mmap1 Not tainted 5.0.0-rc8+ #51 Hardware name: IBM 2964 N63 400 (z/VM 6.4.0) K