Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1220095 > unrolled thread

Multiple potential races on vma->vm_flags

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Multiple potential races on vma->vm_flags "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-09-07 13:50 +0200
    Re: Multiple potential races on vma->vm_flags Vlastimil Babka <vbabka@suse.cz> - 2015-09-09 17:30 +0200
      Re: Multiple potential races on vma->vm_flags "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-09-09 18:10 +0200
    Re: Multiple potential races on vma->vm_flags Sasha Levin <sasha.levin@oracle.com> - 2015-09-10 03:00 +0200
      Re: Multiple potential races on vma->vm_flags "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-09-10 10:40 +0200
        Re: Multiple potential races on vma->vm_flags Andrey Konovalov <andreyknvl@google.com> - 2015-09-10 15:30 +0200
          Re: Multiple potential races on vma->vm_flags "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-09-11 12:50 +0200
            Re: Multiple potential races on vma->vm_flags Vlastimil Babka <vbabka@suse.cz> - 2015-09-11 17:30 +0200
              Re: Multiple potential races on vma->vm_flags Vlastimil Babka <vbabka@suse.cz> - 2015-09-11 18:10 +0200
            Re: Multiple potential races on vma->vm_flags Hugh Dickins <hughd@google.com> - 2015-09-12 03:30 +0200
              Re: Multiple potential races on vma->vm_flags "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-09-14 12:20 +0200
              Re: Multiple potential races on vma->vm_flags Sasha Levin <sasha.levin@oracle.com> - 2015-09-15 19:40 +0200
                Re: Multiple potential races on vma->vm_flags "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-09-15 21:10 +0200

#1220095 — Multiple potential races on vma->vm_flags

On Sun, Sep 06, 2015 at 03:21:05PM -0400, Sasha Levin wrote:
> ==================================================================
> ThreadSanitizer: data-race in munlock_vma_pages_range
> 
> Write of size 8 by thread T378 (K2633, CPU3):
>  [<ffffffff81212579>] munlock_vma_pages_range+0x59/0x3e0 mm/mlock.c:425
>  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
>  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
>  [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
>  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
>  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> arch/x86/entry/entry_64.S:186

...

> Previous read of size 8 by thread T398 (K2623, CPU2):
>  [<ffffffff8121d198>] try_to_unmap_one+0x78/0x4f0 mm/rmap.c:1208
>  [<     inlined    >] rmap_walk+0x147/0x450 rmap_walk_file mm/rmap.c:1540
>  [<ffffffff8121e7b7>] rmap_walk+0x147/0x450 mm/rmap.c:1559
>  [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
>  [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
>  [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
>  [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
>  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
>  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
>  [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
>  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
>  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> arch/x86/entry/entry_64.S:186

Okay, the detected race is mlock/munlock vs. rmap.

On rmap side we check vma->vm_flags in few places without taking
vma->vm_mm->mmap_sem. The vma cannot be freed since we hold i_mmap_rwsem
or anon_vma_lock, but nothing prevent vma->vm_flags from changing under
us.

In this particular case, speculative check in beginning of
try_to_unmap_one() is fine, since we re-check it under mmap_sem later in
the function.

False-negative is fine too here, since we will mlock the page in
__mm_populate() on mlock side after mlock_fixup().

BUT.

We *must* have all speculative vm_flags accesses wrapped READ_ONCE() to
avoid all compiler trickery, like duplication vm_flags access with
inconsistent results.

I looked only on VM_LOCKED checks, but there are few other flags checked
in rmap. All of them must be handled carefully. At least READ_ONCE() is
required.

Other solution would be to introduce per-vma spinlock to protect
vma->vm_flags and probably other vma fields and offload this duty
from mmap_sem.
But that's much bigger project.

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1221525

On 09/07/2015 01:40 PM, Kirill A. Shutemov wrote:
> On Sun, Sep 06, 2015 at 03:21:05PM -0400, Sasha Levin wrote:
>> ==================================================================
>> ThreadSanitizer: data-race in munlock_vma_pages_range
>>
>> Write of size 8 by thread T378 (K2633, CPU3):
>>   [<ffffffff81212579>] munlock_vma_pages_range+0x59/0x3e0 mm/mlock.c:425
>>   [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
>>   [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
>>   [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
>>   [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
>>   [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
>> arch/x86/entry/entry_64.S:186
>
> ...
>
>> Previous read of size 8 by thread T398 (K2623, CPU2):
>>   [<ffffffff8121d198>] try_to_unmap_one+0x78/0x4f0 mm/rmap.c:1208
>>   [<     inlined    >] rmap_walk+0x147/0x450 rmap_walk_file mm/rmap.c:1540
>>   [<ffffffff8121e7b7>] rmap_walk+0x147/0x450 mm/rmap.c:1559
>>   [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
>>   [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
>>   [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
>>   [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
>>   [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
>>   [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
>>   [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
>>   [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
>>   [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
>> arch/x86/entry/entry_64.S:186
>
> Okay, the detected race is mlock/munlock vs. rmap.
>
> On rmap side we check vma->vm_flags in few places without taking
> vma->vm_mm->mmap_sem. The vma cannot be freed since we hold i_mmap_rwsem
> or anon_vma_lock, but nothing prevent vma->vm_flags from changing under
> us.
>
> In this particular case, speculative check in beginning of
> try_to_unmap_one() is fine, since we re-check it under mmap_sem later in
> the function.
>
> False-negative is fine too here, since we will mlock the page in
> __mm_populate() on mlock side after mlock_fixup().
>
> BUT.
>
> We *must* have all speculative vm_flags accesses wrapped READ_ONCE() to
> avoid all compiler trickery, like duplication vm_flags access with
> inconsistent results.

Doesn't taking a semaphore, as in try_to_unmap_one(), already imply a 
compiler barrier forcing vm_flags to be re-read?

> I looked only on VM_LOCKED checks, but there are few other flags checked
> in rmap. All of them must be handled carefully. At least READ_ONCE() is
> required.
>
> Other solution would be to introduce per-vma spinlock to protect
> vma->vm_flags and probably other vma fields and offload this duty
> from mmap_sem.
> But that's much bigger project.

Sounds like an overkill, unless we find something more serious than this.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1221540

On Wed, Sep 09, 2015 at 05:27:16PM +0200, Vlastimil Babka wrote:
> On 09/07/2015 01:40 PM, Kirill A. Shutemov wrote:
> >On Sun, Sep 06, 2015 at 03:21:05PM -0400, Sasha Levin wrote:
> >>==================================================================
> >>ThreadSanitizer: data-race in munlock_vma_pages_range
> >>
> >>Write of size 8 by thread T378 (K2633, CPU3):
> >>  [<ffffffff81212579>] munlock_vma_pages_range+0x59/0x3e0 mm/mlock.c:425
> >>  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
> >>  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
> >>  [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
> >>  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
> >>  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> >>arch/x86/entry/entry_64.S:186
> >
> >...
> >
> >>Previous read of size 8 by thread T398 (K2623, CPU2):
> >>  [<ffffffff8121d198>] try_to_unmap_one+0x78/0x4f0 mm/rmap.c:1208
> >>  [<     inlined    >] rmap_walk+0x147/0x450 rmap_walk_file mm/rmap.c:1540
> >>  [<ffffffff8121e7b7>] rmap_walk+0x147/0x450 mm/rmap.c:1559
> >>  [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
> >>  [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
> >>  [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
> >>  [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
> >>  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
> >>  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
> >>  [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
> >>  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
> >>  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> >>arch/x86/entry/entry_64.S:186
> >
> >Okay, the detected race is mlock/munlock vs. rmap.
> >
> >On rmap side we check vma->vm_flags in few places without taking
> >vma->vm_mm->mmap_sem. The vma cannot be freed since we hold i_mmap_rwsem
> >or anon_vma_lock, but nothing prevent vma->vm_flags from changing under
> >us.
> >
> >In this particular case, speculative check in beginning of
> >try_to_unmap_one() is fine, since we re-check it under mmap_sem later in
> >the function.
> >
> >False-negative is fine too here, since we will mlock the page in
> >__mm_populate() on mlock side after mlock_fixup().
> >
> >BUT.
> >
> >We *must* have all speculative vm_flags accesses wrapped READ_ONCE() to
> >avoid all compiler trickery, like duplication vm_flags access with
> >inconsistent results.
> 
> Doesn't taking a semaphore, as in try_to_unmap_one(), already imply a
> compiler barrier forcing vm_flags to be re-read?

Yes, but it doesn't prevent compiler from generation multiple reads from
vma->vm_flags and it may blow up if two values doesn't match.

> >I looked only on VM_LOCKED checks, but there are few other flags checked
> >in rmap. All of them must be handled carefully. At least READ_ONCE() is
> >required.
> >
> >Other solution would be to introduce per-vma spinlock to protect
> >vma->vm_flags and probably other vma fields and offload this duty
> >from mmap_sem.
> >But that's much bigger project.
> 
> Sounds like an overkill, unless we find something more serious than this.

May be...

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1221832

On 09/07/2015 07:40 AM, Kirill A. Shutemov wrote:
> On Sun, Sep 06, 2015 at 03:21:05PM -0400, Sasha Levin wrote:
>> > ==================================================================
>> > ThreadSanitizer: data-race in munlock_vma_pages_range
>> > 
>> > Write of size 8 by thread T378 (K2633, CPU3):
>> >  [<ffffffff81212579>] munlock_vma_pages_range+0x59/0x3e0 mm/mlock.c:425
>> >  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
>> >  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
>> >  [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
>> >  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
>> >  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
>> > arch/x86/entry/entry_64.S:186
> ...
> 
>> > Previous read of size 8 by thread T398 (K2623, CPU2):
>> >  [<ffffffff8121d198>] try_to_unmap_one+0x78/0x4f0 mm/rmap.c:1208
>> >  [<     inlined    >] rmap_walk+0x147/0x450 rmap_walk_file mm/rmap.c:1540
>> >  [<ffffffff8121e7b7>] rmap_walk+0x147/0x450 mm/rmap.c:1559
>> >  [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
>> >  [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
>> >  [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
>> >  [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
>> >  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
>> >  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
>> >  [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
>> >  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
>> >  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
>> > arch/x86/entry/entry_64.S:186
> Okay, the detected race is mlock/munlock vs. rmap.
> 
> On rmap side we check vma->vm_flags in few places without taking
> vma->vm_mm->mmap_sem. The vma cannot be freed since we hold i_mmap_rwsem
> or anon_vma_lock, but nothing prevent vma->vm_flags from changing under
> us.
> 
> In this particular case, speculative check in beginning of
> try_to_unmap_one() is fine, since we re-check it under mmap_sem later in
> the function.

So you're suggesting that this isn't the cause of the bad page flags
error observed by Andrey and myself?


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222016

On Wed, Sep 09, 2015 at 08:58:26PM -0400, Sasha Levin wrote:
> On 09/07/2015 07:40 AM, Kirill A. Shutemov wrote:
> > On Sun, Sep 06, 2015 at 03:21:05PM -0400, Sasha Levin wrote:
> >> > ==================================================================
> >> > ThreadSanitizer: data-race in munlock_vma_pages_range
> >> > 
> >> > Write of size 8 by thread T378 (K2633, CPU3):
> >> >  [<ffffffff81212579>] munlock_vma_pages_range+0x59/0x3e0 mm/mlock.c:425
> >> >  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
> >> >  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
> >> >  [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
> >> >  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
> >> >  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> >> > arch/x86/entry/entry_64.S:186
> > ...
> > 
> >> > Previous read of size 8 by thread T398 (K2623, CPU2):
> >> >  [<ffffffff8121d198>] try_to_unmap_one+0x78/0x4f0 mm/rmap.c:1208
> >> >  [<     inlined    >] rmap_walk+0x147/0x450 rmap_walk_file mm/rmap.c:1540
> >> >  [<ffffffff8121e7b7>] rmap_walk+0x147/0x450 mm/rmap.c:1559
> >> >  [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
> >> >  [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
> >> >  [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
> >> >  [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
> >> >  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
> >> >  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
> >> >  [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
> >> >  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
> >> >  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> >> > arch/x86/entry/entry_64.S:186
> > Okay, the detected race is mlock/munlock vs. rmap.
> > 
> > On rmap side we check vma->vm_flags in few places without taking
> > vma->vm_mm->mmap_sem. The vma cannot be freed since we hold i_mmap_rwsem
> > or anon_vma_lock, but nothing prevent vma->vm_flags from changing under
> > us.
> > 
> > In this particular case, speculative check in beginning of
> > try_to_unmap_one() is fine, since we re-check it under mmap_sem later in
> > the function.
> 
> So you're suggesting that this isn't the cause of the bad page flags
> error observed by Andrey and myself?

I don't see it, but who knows.

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222189

Can a vma be shared among a few mm's?
If yes, then taking current->mm->mmap_sem to protect vma is not enough.

In the first report below both T378 and T398 take
current->mm->mmap_sem at mm/mlock.c:650, but they turn out to be
different locks (the addresses are different).
In the second report T309 doesn't take any locks at all, since it
assumes that after checking atomic_dec_and_test(&mm->mm_users) the mm
has no other users, but then it does a write to vma.

==================================================================
ThreadSanitizer: data-race in munlock_vma_pages_range

Write of size 8 by thread T378 (K2633, CPU3):
 [<ffffffff81212579>] munlock_vma_pages_range+0x59/0x3e0 mm/mlock.c:425
 [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
 [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
 [<     inlined    >] SYSC_munlock mm/mlock.c:651
 [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
 [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
arch/x86/entry/entry_64.S:186

Locks held by T378:
#0 Lock 25710428 taken here:
 [<     inlined    >] SYSC_munlock mm/mlock.c:650
 [<ffffffff8121308c>] SyS_munlock+0x4c/0xb0 mm/mlock.c:643
 [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
arch/x86/entry/entry_64.S:186

Previous read of size 8 by thread T398 (K2623, CPU2):
 [<ffffffff8121d198>] try_to_unmap_one+0x78/0x4f0 mm/rmap.c:1208
 [<     inlined    >] rmap_walk_file mm/rmap.c:1540
 [<ffffffff8121e7b7>] rmap_walk+0x147/0x450 mm/rmap.c:1559
 [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
 [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
 [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
 [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
 [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
 [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
 [<     inlined    >] SYSC_munlock mm/mlock.c:651
 [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
 [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
arch/x86/entry/entry_64.S:186

Locks held by T398:
#0 Lock 21b00c68 taken here:
 [<     inlined    >] SYSC_munlock mm/mlock.c:650
 [<ffffffff8121308c>] SyS_munlock+0x4c/0xb0 mm/mlock.c:643
 [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
arch/x86/entry/entry_64.S:186
#1 Lock bac2d750 taken here:
 [<     inlined    >] i_mmap_lock_read include/linux/fs.h:509
 [<     inlined    >] rmap_walk_file mm/rmap.c:1533
 [<ffffffff8121e6e8>] rmap_walk+0x78/0x450 mm/rmap.c:1559
 [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
 [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
 [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
 [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
 [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
 [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
 [<     inlined    >] SYSC_munlock mm/mlock.c:651
 [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
 [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
arch/x86/entry/entry_64.S:186
#2 Lock 0895f570 taken here:
 [<     inlined    >] spin_lock include/linux/spinlock.h:312
 [<ffffffff8121c959>] __page_check_address+0xd9/0x210 mm/rmap.c:681
 [<     inlined    >] page_check_address include/linux/rmap.h:204
 [<ffffffff8121d173>] try_to_unmap_one+0x53/0x4f0 mm/rmap.c:1198
 [<     inlined    >] rmap_walk_file mm/rmap.c:1540
 [<ffffffff8121e7b7>] rmap_walk+0x147/0x450 mm/rmap.c:1559
 [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
 [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
 [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
 [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
 [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
 [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
 [<     inlined    >] SYSC_munlock mm/mlock.c:651
 [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
 [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
arch/x86/entry/entry_64.S:186

DBG: addr: ffff880222610e10
DBG: first offset: 0, second offset: 0
DBG: T378 clock: {T378: 4486533, T398: 2405850}
DBG: T398 clock: {T398: 2406009}
==================================================================

==================================================================
ThreadSanitizer: data-race in munlock_vma_pages_range

Write of size 8 by thread T309 (K2577, CPU0):
 [<ffffffff81211fc9>] munlock_vma_pages_range+0x59/0x3e0 mm/mlock.c:425
 [<     inlined    >] munlock_vma_pages_all mm/internal.h:252
 [<ffffffff81216cc3>] exit_mmap+0x163/0x190 mm/mmap.c:2824
 [<ffffffff81085685>] mmput+0x65/0x190 kernel/fork.c:708
 [<     inlined    >] exit_mm kernel/exit.c:437
 [<ffffffff8108c3a7>] do_exit+0x457/0x1420 kernel/exit.c:733
 [<ffffffff8108f08f>] do_group_exit+0x7f/0x140 kernel/exit.c:874
 [<     inlined    >] SYSC_exit_group kernel/exit.c:885
 [<ffffffff8108f170>] __wake_up_parent+0x0/0x50 kernel/exit.c:883
 [<ffffffff81eadb2e>] entry_SYSCALL_64_fastpath+0x12/0x71
arch/x86/entry/entry_64.S:186

Locks held by T309:

Previous read of size 8 by thread T293 (K2573, CPU3):
 [<ffffffff8121cbe8>] try_to_unmap_one+0x78/0x4f0 mm/rmap.c:1208
 [<     inlined    >] rmap_walk_file mm/rmap.c:1540
 [<ffffffff8121e207>] rmap_walk+0x147/0x450 mm/rmap.c:1559
 [<ffffffff8121e9c2>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
 [<ffffffff81211600>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
 [<ffffffff81211ab6>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
 [<ffffffff812122f0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
 [<     inlined    >] munlock_vma_pages_all mm/internal.h:252
 [<ffffffff81216cc3>] exit_mmap+0x163/0x190 mm/mmap.c:2824
 [<ffffffff81085685>] mmput+0x65/0x190 kernel/fork.c:708
 [<     inlined    >] exit_mm kernel/exit.c:437
 [<ffffffff8108c3a7>] do_exit+0x457/0x1420 kernel/exit.c:733
 [<ffffffff8108f08f>] do_group_exit+0x7f/0x140 kernel/exit.c:874
 [<     inlined    >] SYSC_exit_group kernel/exit.c:885
 [<ffffffff8108f170>] __wake_up_parent+0x0/0x50 kernel/exit.c:883
 [<ffffffff81eadb2e>] entry_SYSCALL_64_fastpath+0x12/0x71
arch/x86/entry/entry_64.S:186

Locks held by T293:
#0 Lock bb0dc710 taken here:
 [<     inlined    >] i_mmap_lock_read include/linux/fs.h:509
 [<     inlined    >] rmap_walk_file mm/rmap.c:1533
 [<ffffffff8121e138>] rmap_walk+0x78/0x450 mm/rmap.c:1559
 [<ffffffff8121e9c2>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
 [<ffffffff81211600>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
 [<ffffffff81211ab6>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
 [<ffffffff812122f0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
 [<     inlined    >] munlock_vma_pages_all mm/internal.h:252
 [<ffffffff81216cc3>] exit_mmap+0x163/0x190 mm/mmap.c:2824
 [<ffffffff81085685>] mmput+0x65/0x190 kernel/fork.c:708
 [<     inlined    >] exit_mm kernel/exit.c:437
 [<ffffffff8108c3a7>] do_exit+0x457/0x1420 kernel/exit.c:733
 [<ffffffff8108f08f>] do_group_exit+0x7f/0x140 kernel/exit.c:874
 [<     inlined    >] SYSC_exit_group kernel/exit.c:885
 [<ffffffff8108f170>] __wake_up_parent+0x0/0x50 kernel/exit.c:883
 [<ffffffff81eadb2e>] entry_SYSCALL_64_fastpath+0x12/0x71
arch/x86/entry/entry_64.S:186
#1 Lock 02e0f1b0 taken here:
 [<     inlined    >] spin_lock include/linux/spinlock.h:312
 [<ffffffff8121c3a9>] __page_check_address+0xd9/0x210 mm/rmap.c:681
 [<     inlined    >] page_check_address include/linux/rmap.h:204
 [<ffffffff8121cbc3>] try_to_unmap_one+0x53/0x4f0 mm/rmap.c:1198
 [<     inlined    >] rmap_walk_file mm/rmap.c:1540
 [<ffffffff8121e207>] rmap_walk+0x147/0x450 mm/rmap.c:1559
 [<ffffffff8121e9c2>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
 [<ffffffff81211600>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
 [<ffffffff81211ab6>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
 [<ffffffff812122f0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
 [<     inlined    >] munlock_vma_pages_all mm/internal.h:252
 [<ffffffff81216cc3>] exit_mmap+0x163/0x190 mm/mmap.c:2824
 [<ffffffff81085685>] mmput+0x65/0x190 kernel/fork.c:708
 [<     inlined    >] exit_mm kernel/exit.c:437
 [<ffffffff8108c3a7>] do_exit+0x457/0x1420 kernel/exit.c:733
 [<ffffffff8108f08f>] do_group_exit+0x7f/0x140 kernel/exit.c:874
 [<     inlined    >] SYSC_exit_group kernel/exit.c:885
 [<ffffffff8108f170>] __wake_up_parent+0x0/0x50 kernel/exit.c:883
 [<ffffffff81eadb2e>] entry_SYSCALL_64_fastpath+0x12/0x71
arch/x86/entry/entry_64.S:186

DBG: addr: ffff8800bb153a78
DBG: first offset: 0, second offset: 0
DBG: T309 clock: {T309: 1297809, T293: 747168}
DBG: T293 clock: {T293: 747528}
==================================================================

On Thu, Sep 10, 2015 at 10:36 AM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> On Wed, Sep 09, 2015 at 08:58:26PM -0400, Sasha Levin wrote:
>> On 09/07/2015 07:40 AM, Kirill A. Shutemov wrote:
>> > On Sun, Sep 06, 2015 at 03:21:05PM -0400, Sasha Levin wrote:
>> >> > ==================================================================
>> >> > ThreadSanitizer: data-race in munlock_vma_pages_range
>> >> >
>> >> > Write of size 8 by thread T378 (K2633, CPU3):
>> >> >  [<ffffffff81212579>] munlock_vma_pages_range+0x59/0x3e0 mm/mlock.c:425
>> >> >  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
>> >> >  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
>> >> >  [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
>> >> >  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
>> >> >  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
>> >> > arch/x86/entry/entry_64.S:186
>> > ...
>> >
>> >> > Previous read of size 8 by thread T398 (K2623, CPU2):
>> >> >  [<ffffffff8121d198>] try_to_unmap_one+0x78/0x4f0 mm/rmap.c:1208
>> >> >  [<     inlined    >] rmap_walk+0x147/0x450 rmap_walk_file mm/rmap.c:1540
>> >> >  [<ffffffff8121e7b7>] rmap_walk+0x147/0x450 mm/rmap.c:1559
>> >> >  [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
>> >> >  [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
>> >> >  [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
>> >> >  [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
>> >> >  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
>> >> >  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
>> >> >  [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
>> >> >  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
>> >> >  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
>> >> > arch/x86/entry/entry_64.S:186
>> > Okay, the detected race is mlock/munlock vs. rmap.
>> >
>> > On rmap side we check vma->vm_flags in few places without taking
>> > vma->vm_mm->mmap_sem. The vma cannot be freed since we hold i_mmap_rwsem
>> > or anon_vma_lock, but nothing prevent vma->vm_flags from changing under
>> > us.
>> >
>> > In this particular case, speculative check in beginning of
>> > try_to_unmap_one() is fine, since we re-check it under mmap_sem later in
>> > the function.
>>
>> So you're suggesting that this isn't the cause of the bad page flags
>> error observed by Andrey and myself?
>
> I don't see it, but who knows.
>
> --
>  Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222707

On Thu, Sep 10, 2015 at 03:27:59PM +0200, Andrey Konovalov wrote:
> Can a vma be shared among a few mm's?

Define "shared".

vma can belong only to one process (mm_struct), but it can be accessed
from other process like in rmap case below.

rmap uses anon_vma_lock for anon vma and i_mmap_rwsem for file vma to make
sure that the vma will not disappear under it.

> If yes, then taking current->mm->mmap_sem to protect vma is not enough.

Depends on what protection you are talking about.
 
> In the first report below both T378 and T398 take
> current->mm->mmap_sem at mm/mlock.c:650, but they turn out to be
> different locks (the addresses are different).

See i_mmap_lock_read() in T398. It will guarantee that vma is there.

> In the second report T309 doesn't take any locks at all, since it
> assumes that after checking atomic_dec_and_test(&mm->mm_users) the mm
> has no other users, but then it does a write to vma.

This one is tricky. I *assume* the mm cannot be generally accessible after
mm_users drops to zero, but I'm not entirely sure about it.
procfs? ptrace?

The VMA is still accessible via rmap at this point. And I think it can be
a problem:

		CPU0					CPU1
exit_mmap()
  // mmap_sem is *not* taken
  munlock_vma_pages_all()
    munlock_vma_pages_range()
    						try_to_unmap_one()
						  down_read_trylock(&vma->vm_mm->mmap_sem))
						  !!(vma->vm_flags & VM_LOCKED) == true
      vma->vm_flags &= ~VM_LOCKED;
      <munlock the page>
      						  mlock_vma_page(page);
						  // mlocked pages is leaked.

The obvious solution is to take mmap_sem in exit path, but it would cause
performance regression.

Any comments?

> 
> ==================================================================
> ThreadSanitizer: data-race in munlock_vma_pages_range
> 
> Write of size 8 by thread T378 (K2633, CPU3):
>  [<ffffffff81212579>] munlock_vma_pages_range+0x59/0x3e0 mm/mlock.c:425
>  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
>  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
>  [<     inlined    >] SYSC_munlock mm/mlock.c:651
>  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
>  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> arch/x86/entry/entry_64.S:186
> 
> Locks held by T378:
> #0 Lock 25710428 taken here:
>  [<     inlined    >] SYSC_munlock mm/mlock.c:650
>  [<ffffffff8121308c>] SyS_munlock+0x4c/0xb0 mm/mlock.c:643
>  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> arch/x86/entry/entry_64.S:186
> 
> Previous read of size 8 by thread T398 (K2623, CPU2):
>  [<ffffffff8121d198>] try_to_unmap_one+0x78/0x4f0 mm/rmap.c:1208
>  [<     inlined    >] rmap_walk_file mm/rmap.c:1540
>  [<ffffffff8121e7b7>] rmap_walk+0x147/0x450 mm/rmap.c:1559
>  [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
>  [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
>  [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
>  [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
>  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
>  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
>  [<     inlined    >] SYSC_munlock mm/mlock.c:651
>  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
>  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> arch/x86/entry/entry_64.S:186
> 
> Locks held by T398:
> #0 Lock 21b00c68 taken here:
>  [<     inlined    >] SYSC_munlock mm/mlock.c:650
>  [<ffffffff8121308c>] SyS_munlock+0x4c/0xb0 mm/mlock.c:643
>  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> arch/x86/entry/entry_64.S:186
> #1 Lock bac2d750 taken here:
>  [<     inlined    >] i_mmap_lock_read include/linux/fs.h:509
>  [<     inlined    >] rmap_walk_file mm/rmap.c:1533
>  [<ffffffff8121e6e8>] rmap_walk+0x78/0x450 mm/rmap.c:1559
>  [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
>  [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
>  [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
>  [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
>  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
>  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
>  [<     inlined    >] SYSC_munlock mm/mlock.c:651
>  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
>  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> arch/x86/entry/entry_64.S:186
> #2 Lock 0895f570 taken here:
>  [<     inlined    >] spin_lock include/linux/spinlock.h:312
>  [<ffffffff8121c959>] __page_check_address+0xd9/0x210 mm/rmap.c:681
>  [<     inlined    >] page_check_address include/linux/rmap.h:204
>  [<ffffffff8121d173>] try_to_unmap_one+0x53/0x4f0 mm/rmap.c:1198
>  [<     inlined    >] rmap_walk_file mm/rmap.c:1540
>  [<ffffffff8121e7b7>] rmap_walk+0x147/0x450 mm/rmap.c:1559
>  [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
>  [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
>  [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
>  [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
>  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
>  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
>  [<     inlined    >] SYSC_munlock mm/mlock.c:651
>  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
>  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> arch/x86/entry/entry_64.S:186
> 
> DBG: addr: ffff880222610e10
> DBG: first offset: 0, second offset: 0
> DBG: T378 clock: {T378: 4486533, T398: 2405850}
> DBG: T398 clock: {T398: 2406009}
> ==================================================================
> 
> ==================================================================
> ThreadSanitizer: data-race in munlock_vma_pages_range
> 
> Write of size 8 by thread T309 (K2577, CPU0):
>  [<ffffffff81211fc9>] munlock_vma_pages_range+0x59/0x3e0 mm/mlock.c:425
>  [<     inlined    >] munlock_vma_pages_all mm/internal.h:252
>  [<ffffffff81216cc3>] exit_mmap+0x163/0x190 mm/mmap.c:2824
>  [<ffffffff81085685>] mmput+0x65/0x190 kernel/fork.c:708
>  [<     inlined    >] exit_mm kernel/exit.c:437
>  [<ffffffff8108c3a7>] do_exit+0x457/0x1420 kernel/exit.c:733
>  [<ffffffff8108f08f>] do_group_exit+0x7f/0x140 kernel/exit.c:874
>  [<     inlined    >] SYSC_exit_group kernel/exit.c:885
>  [<ffffffff8108f170>] __wake_up_parent+0x0/0x50 kernel/exit.c:883
>  [<ffffffff81eadb2e>] entry_SYSCALL_64_fastpath+0x12/0x71
> arch/x86/entry/entry_64.S:186
> 
> Locks held by T309:
> 
> Previous read of size 8 by thread T293 (K2573, CPU3):
>  [<ffffffff8121cbe8>] try_to_unmap_one+0x78/0x4f0 mm/rmap.c:1208
>  [<     inlined    >] rmap_walk_file mm/rmap.c:1540
>  [<ffffffff8121e207>] rmap_walk+0x147/0x450 mm/rmap.c:1559
>  [<ffffffff8121e9c2>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
>  [<ffffffff81211600>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
>  [<ffffffff81211ab6>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
>  [<ffffffff812122f0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
>  [<     inlined    >] munlock_vma_pages_all mm/internal.h:252
>  [<ffffffff81216cc3>] exit_mmap+0x163/0x190 mm/mmap.c:2824
>  [<ffffffff81085685>] mmput+0x65/0x190 kernel/fork.c:708
>  [<     inlined    >] exit_mm kernel/exit.c:437
>  [<ffffffff8108c3a7>] do_exit+0x457/0x1420 kernel/exit.c:733
>  [<ffffffff8108f08f>] do_group_exit+0x7f/0x140 kernel/exit.c:874
>  [<     inlined    >] SYSC_exit_group kernel/exit.c:885
>  [<ffffffff8108f170>] __wake_up_parent+0x0/0x50 kernel/exit.c:883
>  [<ffffffff81eadb2e>] entry_SYSCALL_64_fastpath+0x12/0x71
> arch/x86/entry/entry_64.S:186
> 
> Locks held by T293:
> #0 Lock bb0dc710 taken here:
>  [<     inlined    >] i_mmap_lock_read include/linux/fs.h:509
>  [<     inlined    >] rmap_walk_file mm/rmap.c:1533
>  [<ffffffff8121e138>] rmap_walk+0x78/0x450 mm/rmap.c:1559
>  [<ffffffff8121e9c2>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
>  [<ffffffff81211600>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
>  [<ffffffff81211ab6>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
>  [<ffffffff812122f0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
>  [<     inlined    >] munlock_vma_pages_all mm/internal.h:252
>  [<ffffffff81216cc3>] exit_mmap+0x163/0x190 mm/mmap.c:2824
>  [<ffffffff81085685>] mmput+0x65/0x190 kernel/fork.c:708
>  [<     inlined    >] exit_mm kernel/exit.c:437
>  [<ffffffff8108c3a7>] do_exit+0x457/0x1420 kernel/exit.c:733
>  [<ffffffff8108f08f>] do_group_exit+0x7f/0x140 kernel/exit.c:874
>  [<     inlined    >] SYSC_exit_group kernel/exit.c:885
>  [<ffffffff8108f170>] __wake_up_parent+0x0/0x50 kernel/exit.c:883
>  [<ffffffff81eadb2e>] entry_SYSCALL_64_fastpath+0x12/0x71
> arch/x86/entry/entry_64.S:186
> #1 Lock 02e0f1b0 taken here:
>  [<     inlined    >] spin_lock include/linux/spinlock.h:312
>  [<ffffffff8121c3a9>] __page_check_address+0xd9/0x210 mm/rmap.c:681
>  [<     inlined    >] page_check_address include/linux/rmap.h:204
>  [<ffffffff8121cbc3>] try_to_unmap_one+0x53/0x4f0 mm/rmap.c:1198
>  [<     inlined    >] rmap_walk_file mm/rmap.c:1540
>  [<ffffffff8121e207>] rmap_walk+0x147/0x450 mm/rmap.c:1559
>  [<ffffffff8121e9c2>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
>  [<ffffffff81211600>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
>  [<ffffffff81211ab6>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
>  [<ffffffff812122f0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
>  [<     inlined    >] munlock_vma_pages_all mm/internal.h:252
>  [<ffffffff81216cc3>] exit_mmap+0x163/0x190 mm/mmap.c:2824
>  [<ffffffff81085685>] mmput+0x65/0x190 kernel/fork.c:708
>  [<     inlined    >] exit_mm kernel/exit.c:437
>  [<ffffffff8108c3a7>] do_exit+0x457/0x1420 kernel/exit.c:733
>  [<ffffffff8108f08f>] do_group_exit+0x7f/0x140 kernel/exit.c:874
>  [<     inlined    >] SYSC_exit_group kernel/exit.c:885
>  [<ffffffff8108f170>] __wake_up_parent+0x0/0x50 kernel/exit.c:883
>  [<ffffffff81eadb2e>] entry_SYSCALL_64_fastpath+0x12/0x71
> arch/x86/entry/entry_64.S:186
> 
> DBG: addr: ffff8800bb153a78
> DBG: first offset: 0, second offset: 0
> DBG: T309 clock: {T309: 1297809, T293: 747168}
> DBG: T293 clock: {T293: 747528}
> ==================================================================
> 
> On Thu, Sep 10, 2015 at 10:36 AM, Kirill A. Shutemov
> <kirill@shutemov.name> wrote:
> > On Wed, Sep 09, 2015 at 08:58:26PM -0400, Sasha Levin wrote:
> >> On 09/07/2015 07:40 AM, Kirill A. Shutemov wrote:
> >> > On Sun, Sep 06, 2015 at 03:21:05PM -0400, Sasha Levin wrote:
> >> >> > ==================================================================
> >> >> > ThreadSanitizer: data-race in munlock_vma_pages_range
> >> >> >
> >> >> > Write of size 8 by thread T378 (K2633, CPU3):
> >> >> >  [<ffffffff81212579>] munlock_vma_pages_range+0x59/0x3e0 mm/mlock.c:425
> >> >> >  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
> >> >> >  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
> >> >> >  [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
> >> >> >  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
> >> >> >  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> >> >> > arch/x86/entry/entry_64.S:186
> >> > ...
> >> >
> >> >> > Previous read of size 8 by thread T398 (K2623, CPU2):
> >> >> >  [<ffffffff8121d198>] try_to_unmap_one+0x78/0x4f0 mm/rmap.c:1208
> >> >> >  [<     inlined    >] rmap_walk+0x147/0x450 rmap_walk_file mm/rmap.c:1540
> >> >> >  [<ffffffff8121e7b7>] rmap_walk+0x147/0x450 mm/rmap.c:1559
> >> >> >  [<ffffffff8121ef72>] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423
> >> >> >  [<ffffffff81211bb0>] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129
> >> >> >  [<ffffffff81212066>] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331
> >> >> >  [<ffffffff812128a0>] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476
> >> >> >  [<ffffffff81212ac9>] mlock_fixup+0x1c9/0x280 mm/mlock.c:549
> >> >> >  [<ffffffff81212ccc>] do_mlock+0x14c/0x180 mm/mlock.c:589
> >> >> >  [<     inlined    >] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651
> >> >> >  [<ffffffff812130b4>] SyS_munlock+0x74/0xb0 mm/mlock.c:643
> >> >> >  [<ffffffff81eb352e>] entry_SYSCALL_64_fastpath+0x12/0x71
> >> >> > arch/x86/entry/entry_64.S:186
> >> > Okay, the detected race is mlock/munlock vs. rmap.
> >> >
> >> > On rmap side we check vma->vm_flags in few places without taking
> >> > vma->vm_mm->mmap_sem. The vma cannot be freed since we hold i_mmap_rwsem
> >> > or anon_vma_lock, but nothing prevent vma->vm_flags from changing under
> >> > us.
> >> >
> >> > In this particular case, speculative check in beginning of
> >> > try_to_unmap_one() is fine, since we re-check it under mmap_sem later in
> >> > the function.
> >>
> >> So you're suggesting that this isn't the cause of the bad page flags
> >> error observed by Andrey and myself?
> >
> > I don't see it, but who knows.
> >
> > --
> >  Kirill A. Shutemov

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222911

On 09/11/2015 12:39 PM, Kirill A. Shutemov wrote:
> On Thu, Sep 10, 2015 at 03:27:59PM +0200, Andrey Konovalov wrote:
>> Can a vma be shared among a few mm's?
>
> Define "shared".
>
> vma can belong only to one process (mm_struct), but it can be accessed
> from other process like in rmap case below.
>
> rmap uses anon_vma_lock for anon vma and i_mmap_rwsem for file vma to make
> sure that the vma will not disappear under it.
>
>> If yes, then taking current->mm->mmap_sem to protect vma is not enough.
>
> Depends on what protection you are talking about.
>
>> In the first report below both T378 and T398 take
>> current->mm->mmap_sem at mm/mlock.c:650, but they turn out to be
>> different locks (the addresses are different).
>
> See i_mmap_lock_read() in T398. It will guarantee that vma is there.
>
>> In the second report T309 doesn't take any locks at all, since it
>> assumes that after checking atomic_dec_and_test(&mm->mm_users) the mm
>> has no other users, but then it does a write to vma.
>
> This one is tricky. I *assume* the mm cannot be generally accessible after
> mm_users drops to zero, but I'm not entirely sure about it.
> procfs? ptrace?
>
> The VMA is still accessible via rmap at this point. And I think it can be
> a problem:
>
> 		CPU0					CPU1
> exit_mmap()
>    // mmap_sem is *not* taken
>    munlock_vma_pages_all()
>      munlock_vma_pages_range()
>      						try_to_unmap_one()
> 						  down_read_trylock(&vma->vm_mm->mmap_sem))
> 						  !!(vma->vm_flags & VM_LOCKED) == true
>        vma->vm_flags &= ~VM_LOCKED;
>        <munlock the page>
>        						  mlock_vma_page(page);
> 						  // mlocked pages is leaked.
>
> The obvious solution is to take mmap_sem in exit path, but it would cause
> performance regression.
>
> Any comments?

Just so others don't repeat the paths that I already looked at:

- First I thought that try_to_unmap_one() has the page locked and 
munlock_vma_pages_range() will also lock it... but it doesn't.
- Then I thought that exit_mmap() will revisit the page anyway doing 
actual unmap. It would, if it's the one who has the page mapped, it will 
clear the mlock (see page_remove_rmap()). If it's not the last one, page 
will be left locked. So it won't be completely leaked, but still, it 
will be mlocked when it shouldn't.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222927

On 09/11/2015 05:29 PM, Vlastimil Babka wrote:
> On 09/11/2015 12:39 PM, Kirill A. Shutemov wrote:
>> On Thu, Sep 10, 2015 at 03:27:59PM +0200, Andrey Konovalov wrote:
>>> Can a vma be shared among a few mm's?
>>
>> Define "shared".
>>
>> vma can belong only to one process (mm_struct), but it can be accessed
>> from other process like in rmap case below.
>>
>> rmap uses anon_vma_lock for anon vma and i_mmap_rwsem for file vma to make
>> sure that the vma will not disappear under it.
>>
>>> If yes, then taking current->mm->mmap_sem to protect vma is not enough.
>>
>> Depends on what protection you are talking about.
>>
>>> In the first report below both T378 and T398 take
>>> current->mm->mmap_sem at mm/mlock.c:650, but they turn out to be
>>> different locks (the addresses are different).
>>
>> See i_mmap_lock_read() in T398. It will guarantee that vma is there.
>>
>>> In the second report T309 doesn't take any locks at all, since it
>>> assumes that after checking atomic_dec_and_test(&mm->mm_users) the mm
>>> has no other users, but then it does a write to vma.
>>
>> This one is tricky. I *assume* the mm cannot be generally accessible after
>> mm_users drops to zero, but I'm not entirely sure about it.
>> procfs? ptrace?
>>
>> The VMA is still accessible via rmap at this point. And I think it can be
>> a problem:
>>
>> 		CPU0					CPU1
>> exit_mmap()
>>     // mmap_sem is *not* taken
>>     munlock_vma_pages_all()
>>       munlock_vma_pages_range()
>>       						try_to_unmap_one()
>> 						  down_read_trylock(&vma->vm_mm->mmap_sem))
>> 						  !!(vma->vm_flags & VM_LOCKED) == true
>>         vma->vm_flags &= ~VM_LOCKED;
>>         <munlock the page>
>>         						  mlock_vma_page(page);
>> 						  // mlocked pages is leaked.
>>
>> The obvious solution is to take mmap_sem in exit path, but it would cause
>> performance regression.
>>
>> Any comments?
>
> Just so others don't repeat the paths that I already looked at:
>
> - First I thought that try_to_unmap_one() has the page locked and
> munlock_vma_pages_range() will also lock it... but it doesn't.

More precisely, it does (in __munlock_pagevec()), but 
TestClearPageMlocked(page) doesn't happen under that lock.

> - Then I thought that exit_mmap() will revisit the page anyway doing
> actual unmap. It would, if it's the one who has the page mapped, it will
> clear the mlock (see page_remove_rmap()). If it's not the last one, page
> will be left locked. So it won't be completely leaked, but still, it
> will be mlocked when it shouldn't.
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223286

On Fri, 11 Sep 2015, Kirill A. Shutemov wrote:
> On Thu, Sep 10, 2015 at 03:27:59PM +0200, Andrey Konovalov wrote:
> > Can a vma be shared among a few mm's?
> 
> Define "shared".
> 
> vma can belong only to one process (mm_struct), but it can be accessed
> from other process like in rmap case below.
> 
> rmap uses anon_vma_lock for anon vma and i_mmap_rwsem for file vma to make
> sure that the vma will not disappear under it.
> 
> > If yes, then taking current->mm->mmap_sem to protect vma is not enough.
> 
> Depends on what protection you are talking about.
>  
> > In the first report below both T378 and T398 take
> > current->mm->mmap_sem at mm/mlock.c:650, but they turn out to be
> > different locks (the addresses are different).
> 
> See i_mmap_lock_read() in T398. It will guarantee that vma is there.
> 
> > In the second report T309 doesn't take any locks at all, since it
> > assumes that after checking atomic_dec_and_test(&mm->mm_users) the mm
> > has no other users, but then it does a write to vma.
> 
> This one is tricky. I *assume* the mm cannot be generally accessible after
> mm_users drops to zero, but I'm not entirely sure about it.
> procfs? ptrace?

Most of the things (including procfs and ptrace) that need to work on
a foreign mm do take a hold on mm_users with get_task_mm().  swapoff
uses atomic_inc_not_zero(&mm->mm_users).  In KSM I managed to get away
with just a hold on the structure itself, atomic_inc(&mm->mm_count),
and a check for mm_users 0 wherever it down_reads mmap_sem (but Andrey
might like to turn KSM on: it wouldn't be entirely shocking if he were
to discover an anomaly from that).

> 
> The VMA is still accessible via rmap at this point. And I think it can be
> a problem:
> 
> 		CPU0					CPU1
> exit_mmap()
>   // mmap_sem is *not* taken
>   munlock_vma_pages_all()
>     munlock_vma_pages_range()
>     						try_to_unmap_one()
> 						  down_read_trylock(&vma->vm_mm->mmap_sem))
> 						  !!(vma->vm_flags & VM_LOCKED) == true
>       vma->vm_flags &= ~VM_LOCKED;
>       <munlock the page>
>       						  mlock_vma_page(page);
> 						  // mlocked pages is leaked.
> 
> The obvious solution is to take mmap_sem in exit path, but it would cause
> performance regression.
> 
> Any comments?

I'm inclined to echo Vlastimil's comment from earlier in the thread:
sounds like an overkill, unless we find something more serious than this.

I'm not sure whether we'd actually see a regression from taking mmap_sem
in exit path; but given that it's mmap_sem, yes, history tells us please
not to take it any more than we have to.

I do remember wishing, when working out KSM's mm handling, that exit took
mmap_sem: it would have made it simpler, but that wasn't a change I dared
to make.

Maybe an mm_users 0 check after down_read_trylock in try_to_unmap_one() 
could fix it?

But if we were to make a bigger change for this VM_LOCKED issue, and
something more serious makes it worth all the effort, I'd say that
what needs to be done is to give mlock/munlock proper locking (haha).

I have not yet looked at your mlocked THP patch (sorry), but when I
was doing the same thing for huge tmpfs, what made it so surprisingly
difficult was all the spongy trylocking, which concealed the rules.

Maybe I'm completely wrong, but I thought a lot of awkwardness might
disappear if they were relying on anon_vma->rwsem and i_mmap_rwsem
throughout instead of mmap_sem.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224002

On Fri, Sep 11, 2015 at 06:27:14PM -0700, Hugh Dickins wrote:
> On Fri, 11 Sep 2015, Kirill A. Shutemov wrote:
> > On Thu, Sep 10, 2015 at 03:27:59PM +0200, Andrey Konovalov wrote:
> > > Can a vma be shared among a few mm's?
> > 
> > Define "shared".
> > 
> > vma can belong only to one process (mm_struct), but it can be accessed
> > from other process like in rmap case below.
> > 
> > rmap uses anon_vma_lock for anon vma and i_mmap_rwsem for file vma to make
> > sure that the vma will not disappear under it.
> > 
> > > If yes, then taking current->mm->mmap_sem to protect vma is not enough.
> > 
> > Depends on what protection you are talking about.
> >  
> > > In the first report below both T378 and T398 take
> > > current->mm->mmap_sem at mm/mlock.c:650, but they turn out to be
> > > different locks (the addresses are different).
> > 
> > See i_mmap_lock_read() in T398. It will guarantee that vma is there.
> > 
> > > In the second report T309 doesn't take any locks at all, since it
> > > assumes that after checking atomic_dec_and_test(&mm->mm_users) the mm
> > > has no other users, but then it does a write to vma.
> > 
> > This one is tricky. I *assume* the mm cannot be generally accessible after
> > mm_users drops to zero, but I'm not entirely sure about it.
> > procfs? ptrace?
> 
> Most of the things (including procfs and ptrace) that need to work on
> a foreign mm do take a hold on mm_users with get_task_mm().  swapoff
> uses atomic_inc_not_zero(&mm->mm_users).  In KSM I managed to get away
> with just a hold on the structure itself, atomic_inc(&mm->mm_count),
> and a check for mm_users 0 wherever it down_reads mmap_sem (but Andrey
> might like to turn KSM on: it wouldn't be entirely shocking if he were
> to discover an anomaly from that).
> 
> > 
> > The VMA is still accessible via rmap at this point. And I think it can be
> > a problem:
> > 
> > 		CPU0					CPU1
> > exit_mmap()
> >   // mmap_sem is *not* taken
> >   munlock_vma_pages_all()
> >     munlock_vma_pages_range()
> >     						try_to_unmap_one()
> > 						  down_read_trylock(&vma->vm_mm->mmap_sem))
> > 						  !!(vma->vm_flags & VM_LOCKED) == true
> >       vma->vm_flags &= ~VM_LOCKED;
> >       <munlock the page>
> >       						  mlock_vma_page(page);
> > 						  // mlocked pages is leaked.
> > 
> > The obvious solution is to take mmap_sem in exit path, but it would cause
> > performance regression.
> > 
> > Any comments?
> 
> I'm inclined to echo Vlastimil's comment from earlier in the thread:
> sounds like an overkill, unless we find something more serious than this.
> 
> I'm not sure whether we'd actually see a regression from taking mmap_sem
> in exit path; but given that it's mmap_sem, yes, history tells us please
> not to take it any more than we have to.
> 
> I do remember wishing, when working out KSM's mm handling, that exit took
> mmap_sem: it would have made it simpler, but that wasn't a change I dared
> to make.
> 
> Maybe an mm_users 0 check after down_read_trylock in try_to_unmap_one() 
> could fix it?

I don't see how. It would shift a picture, but doesn't fix it: exit_mmap()
can happen after down_read_trylock() and mm_users check.
We would only hide the problem.

> But if we were to make a bigger change for this VM_LOCKED issue, and
> something more serious makes it worth all the effort, I'd say that
> what needs to be done is to give mlock/munlock proper locking (haha).
> 
> I have not yet looked at your mlocked THP patch (sorry), but when I
> was doing the same thing for huge tmpfs, what made it so surprisingly
> difficult was all the spongy trylocking, which concealed the rules.
> 
> Maybe I'm completely wrong, but I thought a lot of awkwardness might
> disappear if they were relying on anon_vma->rwsem and i_mmap_rwsem
> throughout instead of mmap_sem.

This can be helpful. But the risk is getting scalability regression on
other front: long anon_vma chain or highly shared files.

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225461

On 09/11/2015 09:27 PM, Hugh Dickins wrote:
> I'm inclined to echo Vlastimil's comment from earlier in the thread:
> sounds like an overkill, unless we find something more serious than this.

I've modified my tests to stress the exit path of processes with many vmas,
and hit the following NULL ptr deref (not sure if it's related to the original issue):

[1181047.935563] kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
[1181047.937223] Modules linked in:
[1181047.937772] CPU: 4 PID: 21912 Comm: trinity-c341 Not tainted 4.3.0-rc1-next-20150914-sasha-00043-geddd763-dirty #2554
[1181047.939387] task: ffff8804195c8000 ti: ffff880433f00000 task.ti: ffff880433f00000
[1181047.940533] RIP: unmap_vmas (mm/memory.c:1337)
[1181047.941842] RSP: 0000:ffff880433f078a8  EFLAGS: 00010206
[1181047.942383] RAX: dffffc0000000000 RBX: ffff88041acd000a RCX: ffffffffffffffff
[1181047.943091] RDX: 0000000000000099 RSI: ffff88041acd000a RDI: 00000000000004c8
[1181047.943889] RBP: ffff880433f078d8 R08: ffff880415c59c58 R09: 0000000015c59e01
[1181047.944604] R10: 0000000000000000 R11: 0000000000000001 R12: ffffffffffffffff
[1181047.944833] pps pps0: PPS event at 21837.866101174
[1181047.944838] pps pps0: capture assert seq #7188
[1181047.946261] R13: 0000000000000000 R14: ffff880433f07910 R15: 0000000000002e0d
[1181047.947005] FS:  0000000000000000(0000) GS:ffff880252000000(0000) knlGS:0000000000000000
[1181047.947779] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[1181047.948361] CR2: 000000000097df90 CR3: 000000044e08c000 CR4: 00000000000006a0
[1181047.949085] Stack:
[1181047.949350]  0000000000000000 ffff880433f07910 1ffff100867e0f1e dffffc0000000000
[1181047.950164]  ffff8801d825d000 0000000000002e0d ffff880433f079d0 ffffffff9276c4ab
[1181047.951070]  ffff88041acd000a 0000000041b58ab3 ffffffff9ecd1a43 ffffffff9276c2a0
[1181047.951906] Call Trace:
[1181047.952201] exit_mmap (mm/mmap.c:2856)
[1181047.952751] ? SyS_remap_file_pages (mm/mmap.c:2826)
[1181047.953633] ? __khugepaged_exit (./arch/x86/include/asm/atomic.h:118 include/linux/sched.h:2557 mm/huge_memory.c:2169)
[1181047.954281] ? rcu_read_lock_sched_held (kernel/rcu/update.c:109)
[1181047.954936] ? kmem_cache_free (include/trace/events/kmem.h:143 mm/slub.c:2746)
[1181047.955535] ? __khugepaged_exit (./arch/x86/include/asm/atomic.h:118 include/linux/sched.h:2557 mm/huge_memory.c:2169)
[1181047.956204] mmput (include/linux/compiler.h:207 kernel/fork.c:735 kernel/fork.c:702)
[1181047.956691] do_exit (./arch/x86/include/asm/bitops.h:311 include/linux/thread_info.h:91 kernel/exit.c:438 kernel/exit.c:733)
[1181047.957241] ? lockdep_init (kernel/locking/lockdep.c:3298)
[1181047.958005] ? mm_update_next_owner (kernel/exit.c:654)
[1181047.959007] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
[1181047.959995] ? get_lock_stats (kernel/locking/lockdep.c:249)
[1181047.960885] ? lockdep_init (kernel/locking/lockdep.c:3298)
[1181047.961438] ? __raw_callee_save___pv_queued_spin_unlock (??:?)
[1181047.962573] ? lock_release (kernel/locking/lockdep.c:3641)
[1181047.963488] ? __raw_callee_save___pv_queued_spin_unlock (??:?)
[1181047.964704] do_group_exit (./arch/x86/include/asm/current.h:14 kernel/exit.c:859)
[1181047.965569] get_signal (kernel/signal.c:2353)
[1181047.966430] do_signal (arch/x86/kernel/signal.c:709)
[1181047.967241] ? do_readv_writev (include/linux/fsnotify.h:223 fs/read_write.c:821)
[1181047.968169] ? v9fs_file_lock_dotl (fs/9p/vfs_file.c:407)
[1181047.969126] ? vfs_write (fs/read_write.c:777)
[1181047.969955] ? setup_sigcontext (arch/x86/kernel/signal.c:706)
[1181047.970916] ? __raw_callee_save___pv_queued_spin_unlock (??:?)
[1181047.972139] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[1181047.973489] ? _raw_spin_unlock_irq (./arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:171 kernel/locking/spinlock.c:199)
[1181047.974160] ? do_setitimer (include/linux/spinlock.h:357 kernel/time/itimer.c:227)
[1181047.974818] ? check_preemption_disabled (lib/smp_processor_id.c:18)
[1181047.975480] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[1181047.976142] prepare_exit_to_usermode (arch/x86/entry/common.c:251)
[1181047.976784] syscall_return_slowpath (arch/x86/entry/common.c:318)
[1181047.977473] int_ret_from_sys_call (arch/x86/entry/entry_64.S:282)
[1181047.978116] Code: 08 80 3c 02 00 0f 85 22 01 00 00 48 8b 43 40 48 8d b8 c8 04 00 00 48 89 45 d0 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 ee 00 00 00 48 8b 45 d0 48 83 b8 c8 04 00 00
All code
========
   0:   08 80 3c 02 00 0f       or     %al,0xf00023c(%rax)
   6:   85 22                   test   %esp,(%rdx)
   8:   01 00                   add    %eax,(%rax)
   a:   00 48 8b                add    %cl,-0x75(%rax)
   d:   43                      rex.XB
   e:   40                      rex
   f:   48 8d b8 c8 04 00 00    lea    0x4c8(%rax),%rdi
  16:   48 89 45 d0             mov    %rax,-0x30(%rbp)
  1a:   48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
  21:   fc ff df
  24:   48 89 fa                mov    %rdi,%rdx
  27:   48 c1 ea 03             shr    $0x3,%rdx
  2b:*  80 3c 02 00             cmpb   $0x0,(%rdx,%rax,1)               <-- trapping instruction
  2f:   0f 85 ee 00 00 00       jne    0x123
  35:   48 8b 45 d0             mov    -0x30(%rbp),%rax
  39:   48 83 b8 c8 04 00 00    cmpq   $0x0,0x4c8(%rax)
  40:   00

Code starting with the faulting instruction
===========================================
   0:   80 3c 02 00             cmpb   $0x0,(%rdx,%rax,1)
   4:   0f 85 ee 00 00 00       jne    0xf8
   a:   48 8b 45 d0             mov    -0x30(%rbp),%rax
   e:   48 83 b8 c8 04 00 00    cmpq   $0x0,0x4c8(%rax)
  15:   00
[1181047.981417] RIP unmap_vmas (mm/memory.c:1337)
[1181047.982011]  RSP <ffff880433f078a8>


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225515

On Tue, Sep 15, 2015 at 01:36:45PM -0400, Sasha Levin wrote:
> On 09/11/2015 09:27 PM, Hugh Dickins wrote:
> > I'm inclined to echo Vlastimil's comment from earlier in the thread:
> > sounds like an overkill, unless we find something more serious than this.
> 
> I've modified my tests to stress the exit path of processes with many vmas,

Could you share the test?

> and hit the following NULL ptr deref (not sure if it's related to the original issue):
> 
> [1181047.935563] kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
> [1181047.937223] Modules linked in:
> [1181047.937772] CPU: 4 PID: 21912 Comm: trinity-c341 Not tainted 4.3.0-rc1-next-20150914-sasha-00043-geddd763-dirty #2554
> [1181047.939387] task: ffff8804195c8000 ti: ffff880433f00000 task.ti: ffff880433f00000
> [1181047.940533] RIP: unmap_vmas (mm/memory.c:1337)

Is it "struct mm_struct *mm = vma->vm_mm;"?

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web