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

Groups > linux.kernel > #1444520 > unrolled thread

Re: mm: GPF in find_get_pages_tag

Started byRoss Zwisler <ross.zwisler@linux.intel.com>
First post2016-07-15 21:10 +0200
Last post2016-07-15 22:30 +0200
Articles 4 — 2 participants

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

  Re: mm: GPF in find_get_pages_tag Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-07-15 21:10 +0200
    Re: mm: GPF in find_get_pages_tag Dmitry Vyukov <dvyukov@google.com> - 2016-07-15 21:10 +0200
      Re: mm: GPF in find_get_pages_tag Dmitry Vyukov <dvyukov@google.com> - 2016-07-15 22:30 +0200
      Re: mm: GPF in find_get_pages_tag Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-07-15 22:30 +0200

#1444520 — Re: mm: GPF in find_get_pages_tag

FromRoss Zwisler <ross.zwisler@linux.intel.com>
Date2016-07-15 21:10 +0200
SubjectRe: mm: GPF in find_get_pages_tag
Message-ID<rVgEO-2iR-11@gated-at.bofh.it>
On Tue, Jul 05, 2016 at 01:39:23PM +0200, Dmitry Vyukov wrote:
> Hello,
> 
> The following program triggers GPF in find_get_pages_tag if run in
> parallel loop for minutes:
> 
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
> Modules linked in:
> CPU: 2 PID: 301 Comm: a.out Tainted: G        W       4.7.0-rc5+ #28
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: ffff880063d12440 ti: ffff880067350000 task.ti: ffff880067350000
> RIP: 0010:[<ffffffff816951a4>]
>   [<     inline     >] radix_tree_next_slot include/linux/radix-tree.h:473
>   [<ffffffff816951a4>] find_get_pages_tag+0x334/0x930 mm/filemap.c:1452
> RSP: 0018:ffff880067357840  EFLAGS: 00010202
> RAX: 0000000000000001 RBX: 0000000000000001 RCX: ffff880063d12c80
> RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000000008
> RBP: ffff880067357910 R08: 0000000000000002 R09: 0000000000000000
> R10: 0000000000000000 R11: ffffffff89f06360 R12: 0000000000000001
> R13: 0000000000000000 R14: 0000000000000000 R15: ffffed0007058ee5
> FS:  00007f56e017c700(0000) GS:ffff88006d400000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f56df97ae78 CR3: 0000000063d9e000 CR4: 00000000000006e0
> Stack:
>  ffffffff81694efc ffff8800673578a8 0000010267357860 ffff880067357a50
>  ffff880065986aa0 1ffff1000ce6af11 0000000e00000000 ffff880067357a00
>  0000000000000003 0000000041b58ab3 ffffffff87e2a722 ffffffff81694e70
> Call Trace:
>  [<ffffffff816cd91a>] pagevec_lookup_tag+0x3a/0x80 mm/swap.c:960
>  [<ffffffff81ab4231>] mpage_prepare_extent_to_map+0x321/0xa90
> fs/ext4/inode.c:2516
>  [<ffffffff81ac883e>] ext4_writepages+0x10be/0x2b20 fs/ext4/inode.c:2736
>  [<ffffffff816c99c7>] do_writepages+0x97/0x100 mm/page-writeback.c:2364
>  [<ffffffff8169bee8>] __filemap_fdatawrite_range+0x248/0x2e0 mm/filemap.c:300
>  [<ffffffff8169c371>] filemap_write_and_wait_range+0x121/0x1b0 mm/filemap.c:490
>  [<ffffffff81aa584d>] ext4_sync_file+0x34d/0xdb0 fs/ext4/fsync.c:115
>  [<ffffffff818b667a>] vfs_fsync_range+0x10a/0x250 fs/sync.c:195
>  [<     inline     >] vfs_fsync fs/sync.c:209
>  [<ffffffff818b6832>] do_fsync+0x42/0x70 fs/sync.c:219
>  [<     inline     >] SYSC_fdatasync fs/sync.c:232
>  [<ffffffff818b6f89>] SyS_fdatasync+0x19/0x20 fs/sync.c:230
>  [<ffffffff86a94e00>] entry_SYSCALL_64_fastpath+0x23/0xc1
> arch/x86/entry/entry_64.S:207
> Code: 85 70 ff ff ff 49 d1 ec 4d 85 e4 4c 89 65 a8 74 65 e8 51 06 f0
> ff 49 8d 7e 08 48 be 00 00 00 00 00 fc ff df 48 89 f8 48 c1 e8 03 <80>
> 3c 30 00 0f 85 9c 05 00 00 4d 8b 6e 08 4c 89 eb 83 e3 03 48
> RIP  [<     inline     >] radix_tree_next_slot include/linux/radix-tree.h:473
> RIP  [<ffffffff816951a4>] find_get_pages_tag+0x334/0x930 mm/filemap.c:1452
>  RSP <ffff880067357840>
> ---[ end trace 33a0cc4dd9a49a67 ]---
> 
> 
> 
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <pthread.h>
> #include <stdint.h>
> #include <string.h>
> #include <stdio.h>
> #include <sys/syscall.h>
> #include <unistd.h>
> 
> int fd;
> char buf[8192];
> char filename[256];
> 
> void* thr(void* arg)
> {
>   switch ((long)arg) {
>   case 0:
>     write(fd, buf, 0x1001ul);
>     break;
>   case 1:
>     fdatasync(fd);
>     break;
>   case 2:
>     ftruncate(fd, 2);
>     break;
>   case 3:
>     write(fd, buf, 0x20ul);
>     break;
>   case 5:
>     fd = open(filename, 0x50042ul, 0x41ul);
>     break;

This open() code is unreachable because the thread argument will only be 0-4,
right?  Should this be "case 4"?

>   }
>   return 0;
> }
> 
> int main()
> {
>   long i;
>   pthread_t th[10];
> 
>   srand(getpid());
>   sprintf(filename, "./file%d", getpid());
>   fd = open(filename, 0x50042ul, 0x41ul);
>   for (i = 0; i < 10; i++) {
>     pthread_create(&th[i], 0, thr, (void*)(i % 5));
>     usleep(rand() % 10);
>   }
>   for (i = 0; i < 10; i++)
>     pthread_join(th[i], 0);
>   unlink(filename);
>   return 0;
> }
> 
> The faulting instruction is:
> ffffffff816951a4:       80 3c 30 00             cmpb   $0x0,(%rax,%rsi,1)
> So this is KASAN shadow check for NULL address.
> 
> 
> The previous taint is not relevant, it is:
> 
> [   74.786477] ------------[ cut here ]------------
> [   74.786885] WARNING: CPU: 2 PID: 717 at lib/stackdepot.c:119
> depot_save_stack+0x34f/0x5b0
> [   74.787196] Stack depot reached limit capacity
> 
> 
> On commit 1a0a02d1efa066001fd315c1b4df583d939fa2c4 (Jun 30).

[toc] | [next] | [standalone]

#1444523

FromDmitry Vyukov <dvyukov@google.com>
Date2016-07-15 21:10 +0200
Message-ID<rVgEO-2iR-27@gated-at.bofh.it>
In reply to#1444520
On Fri, Jul 15, 2016 at 9:03 PM, Ross Zwisler
<ross.zwisler@linux.intel.com> wrote:
> On Tue, Jul 05, 2016 at 01:39:23PM +0200, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers GPF in find_get_pages_tag if run in
>> parallel loop for minutes:
>>
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
>> Modules linked in:
>> CPU: 2 PID: 301 Comm: a.out Tainted: G        W       4.7.0-rc5+ #28
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: ffff880063d12440 ti: ffff880067350000 task.ti: ffff880067350000
>> RIP: 0010:[<ffffffff816951a4>]
>>   [<     inline     >] radix_tree_next_slot include/linux/radix-tree.h:473
>>   [<ffffffff816951a4>] find_get_pages_tag+0x334/0x930 mm/filemap.c:1452
>> RSP: 0018:ffff880067357840  EFLAGS: 00010202
>> RAX: 0000000000000001 RBX: 0000000000000001 RCX: ffff880063d12c80
>> RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000000008
>> RBP: ffff880067357910 R08: 0000000000000002 R09: 0000000000000000
>> R10: 0000000000000000 R11: ffffffff89f06360 R12: 0000000000000001
>> R13: 0000000000000000 R14: 0000000000000000 R15: ffffed0007058ee5
>> FS:  00007f56e017c700(0000) GS:ffff88006d400000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00007f56df97ae78 CR3: 0000000063d9e000 CR4: 00000000000006e0
>> Stack:
>>  ffffffff81694efc ffff8800673578a8 0000010267357860 ffff880067357a50
>>  ffff880065986aa0 1ffff1000ce6af11 0000000e00000000 ffff880067357a00
>>  0000000000000003 0000000041b58ab3 ffffffff87e2a722 ffffffff81694e70
>> Call Trace:
>>  [<ffffffff816cd91a>] pagevec_lookup_tag+0x3a/0x80 mm/swap.c:960
>>  [<ffffffff81ab4231>] mpage_prepare_extent_to_map+0x321/0xa90
>> fs/ext4/inode.c:2516
>>  [<ffffffff81ac883e>] ext4_writepages+0x10be/0x2b20 fs/ext4/inode.c:2736
>>  [<ffffffff816c99c7>] do_writepages+0x97/0x100 mm/page-writeback.c:2364
>>  [<ffffffff8169bee8>] __filemap_fdatawrite_range+0x248/0x2e0 mm/filemap.c:300
>>  [<ffffffff8169c371>] filemap_write_and_wait_range+0x121/0x1b0 mm/filemap.c:490
>>  [<ffffffff81aa584d>] ext4_sync_file+0x34d/0xdb0 fs/ext4/fsync.c:115
>>  [<ffffffff818b667a>] vfs_fsync_range+0x10a/0x250 fs/sync.c:195
>>  [<     inline     >] vfs_fsync fs/sync.c:209
>>  [<ffffffff818b6832>] do_fsync+0x42/0x70 fs/sync.c:219
>>  [<     inline     >] SYSC_fdatasync fs/sync.c:232
>>  [<ffffffff818b6f89>] SyS_fdatasync+0x19/0x20 fs/sync.c:230
>>  [<ffffffff86a94e00>] entry_SYSCALL_64_fastpath+0x23/0xc1
>> arch/x86/entry/entry_64.S:207
>> Code: 85 70 ff ff ff 49 d1 ec 4d 85 e4 4c 89 65 a8 74 65 e8 51 06 f0
>> ff 49 8d 7e 08 48 be 00 00 00 00 00 fc ff df 48 89 f8 48 c1 e8 03 <80>
>> 3c 30 00 0f 85 9c 05 00 00 4d 8b 6e 08 4c 89 eb 83 e3 03 48
>> RIP  [<     inline     >] radix_tree_next_slot include/linux/radix-tree.h:473
>> RIP  [<ffffffff816951a4>] find_get_pages_tag+0x334/0x930 mm/filemap.c:1452
>>  RSP <ffff880067357840>
>> ---[ end trace 33a0cc4dd9a49a67 ]---
>>
>>
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #include <pthread.h>
>> #include <stdint.h>
>> #include <string.h>
>> #include <stdio.h>
>> #include <sys/syscall.h>
>> #include <unistd.h>
>>
>> int fd;
>> char buf[8192];
>> char filename[256];
>>
>> void* thr(void* arg)
>> {
>>   switch ((long)arg) {
>>   case 0:
>>     write(fd, buf, 0x1001ul);
>>     break;
>>   case 1:
>>     fdatasync(fd);
>>     break;
>>   case 2:
>>     ftruncate(fd, 2);
>>     break;
>>   case 3:
>>     write(fd, buf, 0x20ul);
>>     break;
>>   case 5:
>>     fd = open(filename, 0x50042ul, 0x41ul);
>>     break;
>
> This open() code is unreachable because the thread argument will only be 0-4,
> right?  Should this be "case 4"?


I am not sure. I think it I just copy-pasted the program that
triggered the crash for me. Andrey should have a valid reproducer, in
the other thread he said that he can reproduce it. Andrey, did you
change 5 to 4?



>>   }
>>   return 0;
>> }
>>
>> int main()
>> {
>>   long i;
>>   pthread_t th[10];
>>
>>   srand(getpid());
>>   sprintf(filename, "./file%d", getpid());
>>   fd = open(filename, 0x50042ul, 0x41ul);
>>   for (i = 0; i < 10; i++) {
>>     pthread_create(&th[i], 0, thr, (void*)(i % 5));
>>     usleep(rand() % 10);
>>   }
>>   for (i = 0; i < 10; i++)
>>     pthread_join(th[i], 0);
>>   unlink(filename);
>>   return 0;
>> }
>>
>> The faulting instruction is:
>> ffffffff816951a4:       80 3c 30 00             cmpb   $0x0,(%rax,%rsi,1)
>> So this is KASAN shadow check for NULL address.
>>
>>
>> The previous taint is not relevant, it is:
>>
>> [   74.786477] ------------[ cut here ]------------
>> [   74.786885] WARNING: CPU: 2 PID: 717 at lib/stackdepot.c:119
>> depot_save_stack+0x34f/0x5b0
>> [   74.787196] Stack depot reached limit capacity
>>
>>
>> On commit 1a0a02d1efa066001fd315c1b4df583d939fa2c4 (Jun 30).
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

#1444554

FromDmitry Vyukov <dvyukov@google.com>
Date2016-07-15 22:30 +0200
Message-ID<rVhUe-2YB-5@gated-at.bofh.it>
In reply to#1444523
On Fri, Jul 15, 2016 at 10:21 PM, Ross Zwisler
<ross.zwisler@linux.intel.com> wrote:
> On Fri, Jul 15, 2016 at 09:07:48PM +0200, Dmitry Vyukov wrote:
>> On Fri, Jul 15, 2016 at 9:03 PM, Ross Zwisler
>> <ross.zwisler@linux.intel.com> wrote:
>> >> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> >> #include <pthread.h>
>> >> #include <stdint.h>
>> >> #include <string.h>
>> >> #include <stdio.h>
>> >> #include <sys/syscall.h>
>> >> #include <unistd.h>
>> >>
>> >> int fd;
>> >> char buf[8192];
>> >> char filename[256];
>> >>
>> >> void* thr(void* arg)
>> >> {
>> >>   switch ((long)arg) {
>> >>   case 0:
>> >>     write(fd, buf, 0x1001ul);
>> >>     break;
>> >>   case 1:
>> >>     fdatasync(fd);
>> >>     break;
>> >>   case 2:
>> >>     ftruncate(fd, 2);
>> >>     break;
>> >>   case 3:
>> >>     write(fd, buf, 0x20ul);
>> >>     break;
>> >>   case 5:
>> >>     fd = open(filename, 0x50042ul, 0x41ul);
>> >>     break;
>> >
>> > This open() code is unreachable because the thread argument will only be 0-4,
>> > right?  Should this be "case 4"?
>>
>> I am not sure. I think it I just copy-pasted the program that
>> triggered the crash for me. Andrey should have a valid reproducer, in
>> the other thread he said that he can reproduce it. Andrey, did you
>> change 5 to 4?
>
> Ah, sorry if I wasn't clear.  I don't think you need the open() call to have a
> valid reproducer.  In mine, in fact, I only use the first three - the error
> happens with a combination of write(), fdatasync() and ftruncate().
>
> I just wanted to note that the test program (which was autogenerated?) had an
> unreachable case in the switch() statement. :)
>
> Thanks for this testing, by the way!


Ah, OK. I modified the program by hand to make it trigger the bug more
frequently. So I think the bug was introduced by me. Generator should
not generate dead cases.

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

#1444557

FromRoss Zwisler <ross.zwisler@linux.intel.com>
Date2016-07-15 22:30 +0200
Message-ID<rVhUe-2YB-7@gated-at.bofh.it>
In reply to#1444523
On Fri, Jul 15, 2016 at 09:07:48PM +0200, Dmitry Vyukov wrote:
> On Fri, Jul 15, 2016 at 9:03 PM, Ross Zwisler
> <ross.zwisler@linux.intel.com> wrote:
> >> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> >> #include <pthread.h>
> >> #include <stdint.h>
> >> #include <string.h>
> >> #include <stdio.h>
> >> #include <sys/syscall.h>
> >> #include <unistd.h>
> >>
> >> int fd;
> >> char buf[8192];
> >> char filename[256];
> >>
> >> void* thr(void* arg)
> >> {
> >>   switch ((long)arg) {
> >>   case 0:
> >>     write(fd, buf, 0x1001ul);
> >>     break;
> >>   case 1:
> >>     fdatasync(fd);
> >>     break;
> >>   case 2:
> >>     ftruncate(fd, 2);
> >>     break;
> >>   case 3:
> >>     write(fd, buf, 0x20ul);
> >>     break;
> >>   case 5:
> >>     fd = open(filename, 0x50042ul, 0x41ul);
> >>     break;
> >
> > This open() code is unreachable because the thread argument will only be 0-4,
> > right?  Should this be "case 4"?
> 
> I am not sure. I think it I just copy-pasted the program that
> triggered the crash for me. Andrey should have a valid reproducer, in
> the other thread he said that he can reproduce it. Andrey, did you
> change 5 to 4?

Ah, sorry if I wasn't clear.  I don't think you need the open() call to have a
valid reproducer.  In mine, in fact, I only use the first three - the error
happens with a combination of write(), fdatasync() and ftruncate().

I just wanted to note that the test program (which was autogenerated?) had an
unreachable case in the switch() statement. :)

Thanks for this testing, by the way!

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web