linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* mm: fault in __do_fault
@ 2017-02-28 14:04 Dmitry Vyukov
  2017-02-28 15:32 ` Kirill A. Shutemov
  2017-02-28 15:42 ` Andrea Arcangeli
  0 siblings, 2 replies; 5+ messages in thread
From: Dmitry Vyukov @ 2017-02-28 14:04 UTC (permalink / raw)
  To: Andrew Morton, Kirill A. Shutemov, Jan Kara, ross.zwisler,
	Michal Hocko, linux-mm, LKML, Andrea Arcangeli, Mike Kravetz
  Cc: syzkaller

Hello,

The following program triggers GPF in __do_fault:
https://gist.githubusercontent.com/dvyukov/27345737fca18d92ef761e7fa08aec9b/raw/d99d02511d0bf9a8d6f6bd9c79d373a26924e974/gistfile1.txt

general protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 3 PID: 2955 Comm: a.out Not tainted 4.10.0+ #230
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88006b4e2480 task.stack: ffff88006b0b0000
RIP: 0010:__read_once_size include/linux/compiler.h:247 [inline]
RIP: 0010:compound_head include/linux/page-flags.h:146 [inline]
RIP: 0010:trylock_page include/linux/pagemap.h:442 [inline]
RIP: 0010:lock_page include/linux/pagemap.h:452 [inline]
RIP: 0010:__do_fault+0x247/0x3e0 mm/memory.c:2898
RSP: 0000:ffff88006b0b7470 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 1ffff1000d616e91 RCX: 0000000000000000
RDX: 0000000000000004 RSI: dffffc0000000000 RDI: 0000000000000020
RBP: ffff88006b0b7550 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000004 R12: ffff88006b0b74e8
R13: 0000000000000000 R14: ffff88006b0b7528 R15: 0000000000000000
FS:  00007fef8bb55700(0000) GS:ffff88006d180000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020012fe0 CR3: 000000006a8dc000 CR4: 00000000001406e0
Call Trace:
 do_read_fault mm/memory.c:3266 [inline]
 do_fault+0x5ee/0x2080 mm/memory.c:3366
 handle_pte_fault mm/memory.c:3596 [inline]
 __handle_mm_fault+0x1062/0x2cb0 mm/memory.c:3710
 handle_mm_fault+0x1e2/0x480 mm/memory.c:3747
 __do_page_fault+0x4f6/0xb60 arch/x86/mm/fault.c:1396
 trace_do_page_fault+0x141/0x6c0 arch/x86/mm/fault.c:1489
 do_async_page_fault+0x72/0xc0 arch/x86/kernel/kvm.c:264
 async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:1014
RIP: 0033:0x43dda0
RSP: 002b:00007fef8bb54878 EFLAGS: 00010202
RAX: 00007fef8bb548b0 RBX: 0000000000000000 RCX: 000000000000000e
RDX: 0000000000000400 RSI: 0000000020012fe0 RDI: 00007fef8bb548b0
RBP: 00007fef8bb54cd0 R08: 0000000000000400 R09: 00007fef8bb54d10
R10: 00007fef8bb559d0 R11: 0000000000000202 R12: 0000000000000000
R13: 0000000000000000 R14: 00007fef8bb559c0 R15: 00007fef8bb55700
Code: 00 e8 0e 35 b8 ff e8 79 09 a2 02 4c 89 e2 49 8d 7f 20 48 b8 00
00 00 00 00 fc ff df 48 c1 ea 03 c6 04 02 00 48 89 fa 48 c1 ea 03 <80>
3c 02 00 0f 85 ec 00 00 00 4c 89 e2 48 b8 00 00 00 00 00 fc
RIP: __read_once_size include/linux/compiler.h:247 [inline] RSP:
ffff88006b0b7470
RIP: compound_head include/linux/page-flags.h:146 [inline] RSP: ffff88006b0b7470
RIP: trylock_page include/linux/pagemap.h:442 [inline] RSP: ffff88006b0b7470
RIP: lock_page include/linux/pagemap.h:452 [inline] RSP: ffff88006b0b7470
RIP: __do_fault+0x247/0x3e0 mm/memory.c:2898 RSP: ffff88006b0b7470
---[ end trace d24250eecdbb8a34 ]---

On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: mm: fault in __do_fault
  2017-02-28 14:04 mm: fault in __do_fault Dmitry Vyukov
@ 2017-02-28 15:32 ` Kirill A. Shutemov
  2017-02-28 15:55   ` Andrea Arcangeli
  2017-02-28 15:42 ` Andrea Arcangeli
  1 sibling, 1 reply; 5+ messages in thread
From: Kirill A. Shutemov @ 2017-02-28 15:32 UTC (permalink / raw)
  To: Dmitry Vyukov, Andrea Arcangeli
  Cc: Andrew Morton, Kirill A. Shutemov, Jan Kara, ross.zwisler,
	Michal Hocko, linux-mm, LKML, Mike Kravetz, syzkaller

On Tue, Feb 28, 2017 at 03:04:53PM +0100, Dmitry Vyukov wrote:
> Hello,
> 
> The following program triggers GPF in __do_fault:
> https://gist.githubusercontent.com/dvyukov/27345737fca18d92ef761e7fa08aec9b/raw/d99d02511d0bf9a8d6f6bd9c79d373a26924e974/gistfile1.txt
> 
> general protection fault: 0000 [#1] SMP KASAN
> Modules linked in:
> CPU: 3 PID: 2955 Comm: a.out Not tainted 4.10.0+ #230
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: ffff88006b4e2480 task.stack: ffff88006b0b0000
> RIP: 0010:__read_once_size include/linux/compiler.h:247 [inline]
> RIP: 0010:compound_head include/linux/page-flags.h:146 [inline]
> RIP: 0010:trylock_page include/linux/pagemap.h:442 [inline]
> RIP: 0010:lock_page include/linux/pagemap.h:452 [inline]
> RIP: 0010:__do_fault+0x247/0x3e0 mm/memory.c:2898
> RSP: 0000:ffff88006b0b7470 EFLAGS: 00010202
> RAX: dffffc0000000000 RBX: 1ffff1000d616e91 RCX: 0000000000000000
> RDX: 0000000000000004 RSI: dffffc0000000000 RDI: 0000000000000020
> RBP: ffff88006b0b7550 R08: 0000000000000001 R09: 0000000000000001
> R10: 0000000000000000 R11: 0000000000000004 R12: ffff88006b0b74e8
> R13: 0000000000000000 R14: ffff88006b0b7528 R15: 0000000000000000
> FS:  00007fef8bb55700(0000) GS:ffff88006d180000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020012fe0 CR3: 000000006a8dc000 CR4: 00000000001406e0
> Call Trace:
>  do_read_fault mm/memory.c:3266 [inline]
>  do_fault+0x5ee/0x2080 mm/memory.c:3366
>  handle_pte_fault mm/memory.c:3596 [inline]
>  __handle_mm_fault+0x1062/0x2cb0 mm/memory.c:3710
>  handle_mm_fault+0x1e2/0x480 mm/memory.c:3747
>  __do_page_fault+0x4f6/0xb60 arch/x86/mm/fault.c:1396
>  trace_do_page_fault+0x141/0x6c0 arch/x86/mm/fault.c:1489
>  do_async_page_fault+0x72/0xc0 arch/x86/kernel/kvm.c:264
>  async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:1014
> RIP: 0033:0x43dda0
> RSP: 002b:00007fef8bb54878 EFLAGS: 00010202
> RAX: 00007fef8bb548b0 RBX: 0000000000000000 RCX: 000000000000000e
> RDX: 0000000000000400 RSI: 0000000020012fe0 RDI: 00007fef8bb548b0
> RBP: 00007fef8bb54cd0 R08: 0000000000000400 R09: 00007fef8bb54d10
> R10: 00007fef8bb559d0 R11: 0000000000000202 R12: 0000000000000000
> R13: 0000000000000000 R14: 00007fef8bb559c0 R15: 00007fef8bb55700
> Code: 00 e8 0e 35 b8 ff e8 79 09 a2 02 4c 89 e2 49 8d 7f 20 48 b8 00
> 00 00 00 00 fc ff df 48 c1 ea 03 c6 04 02 00 48 89 fa 48 c1 ea 03 <80>
> 3c 02 00 0f 85 ec 00 00 00 4c 89 e2 48 b8 00 00 00 00 00 fc
> RIP: __read_once_size include/linux/compiler.h:247 [inline] RSP:
> ffff88006b0b7470
> RIP: compound_head include/linux/page-flags.h:146 [inline] RSP: ffff88006b0b7470
> RIP: trylock_page include/linux/pagemap.h:442 [inline] RSP: ffff88006b0b7470
> RIP: lock_page include/linux/pagemap.h:452 [inline] RSP: ffff88006b0b7470
> RIP: __do_fault+0x247/0x3e0 mm/memory.c:2898 RSP: ffff88006b0b7470

__do_fault() expects to see a page if ->fault() returns zero, but
handle_userfault() mess this up, making shmem_fault() return 0 without
setting vmf->page.

I'm not entirely sure it's fully correct, but the patch below fixes the
crash for me.

Andrea, does it look okay for you?

diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index 625b7285a37b..56f61f1a1dc1 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -489,7 +489,7 @@ int handle_userfault(struct vm_fault *vmf, unsigned long reason)
                         * in such case.
                         */
                        down_read(&mm->mmap_sem);
-                       ret = 0;
+                       ret = VM_FAULT_NOPAGE;
                }
        }

-- 
 Kirill A. Shutemov

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: mm: fault in __do_fault
  2017-02-28 14:04 mm: fault in __do_fault Dmitry Vyukov
  2017-02-28 15:32 ` Kirill A. Shutemov
@ 2017-02-28 15:42 ` Andrea Arcangeli
  2017-03-03  7:42   ` Dmitry Vyukov
  1 sibling, 1 reply; 5+ messages in thread
From: Andrea Arcangeli @ 2017-02-28 15:42 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Andrew Morton, Kirill A. Shutemov, Jan Kara, ross.zwisler,
	Michal Hocko, linux-mm, LKML, Mike Kravetz, syzkaller

Hello Dmitry,

On Tue, Feb 28, 2017 at 03:04:53PM +0100, Dmitry Vyukov wrote:
> Hello,
> 
> The following program triggers GPF in __do_fault:
> https://gist.githubusercontent.com/dvyukov/27345737fca18d92ef761e7fa08aec9b/raw/d99d02511d0bf9a8d6f6bd9c79d373a26924e974/gistfile1.txt

Can you verify this fix:

>From a65381bc86d2963713b6a9c4a73cded7dd184282 Mon Sep 17 00:00:00 2001
From: Andrea Arcangeli <aarcange@redhat.com>
Date: Tue, 28 Feb 2017 16:36:59 +0100
Subject: [PATCH 1/1] userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE

__do_fault assumes vmf->page has been initialized and is valid if
VM_FAULT_NOPAGE is not returned by vma->vm_ops->fault(vma, vmf).

handle_userfault() in turn should return VM_FAULT_NOPAGE if it doesn't
return VM_FAULT_SIGBUS or VM_FAULT_RETRY (the other two
possibilities).

This VM_FAULT_NOPAGE case is only invoked when signal are pending and
it didn't matter for anonymous memory before. It only started to
matter since shmem was introduced. hugetlbfs also takes a different
path and doesn't exercise __do_fault.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
 fs/userfaultfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index fb6d02b..de28f43 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -500,7 +500,7 @@ int handle_userfault(struct vm_fault *vmf, unsigned long reason)
 			 * in such case.
 			 */
 			down_read(&mm->mmap_sem);
-			ret = 0;
+			ret = VM_FAULT_NOPAGE;
 		}
 	}
 

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: mm: fault in __do_fault
  2017-02-28 15:32 ` Kirill A. Shutemov
@ 2017-02-28 15:55   ` Andrea Arcangeli
  0 siblings, 0 replies; 5+ messages in thread
From: Andrea Arcangeli @ 2017-02-28 15:55 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Dmitry Vyukov, Andrew Morton, Kirill A. Shutemov, Jan Kara,
	ross.zwisler, Michal Hocko, linux-mm, LKML, Mike Kravetz,
	syzkaller

On Tue, Feb 28, 2017 at 06:32:20PM +0300, Kirill A. Shutemov wrote:
> Andrea, does it look okay for you?
> 
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index 625b7285a37b..56f61f1a1dc1 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -489,7 +489,7 @@ int handle_userfault(struct vm_fault *vmf, unsigned long reason)
>                          * in such case.
>                          */
>                         down_read(&mm->mmap_sem);
> -                       ret = 0;
> +                       ret = VM_FAULT_NOPAGE;
>                 }
>         }

Yes, I did the same fix.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: mm: fault in __do_fault
  2017-02-28 15:42 ` Andrea Arcangeli
@ 2017-03-03  7:42   ` Dmitry Vyukov
  0 siblings, 0 replies; 5+ messages in thread
From: Dmitry Vyukov @ 2017-03-03  7:42 UTC (permalink / raw)
  To: Andrea Arcangeli
  Cc: Andrew Morton, Kirill A. Shutemov, Jan Kara, ross.zwisler,
	Michal Hocko, linux-mm, LKML, Mike Kravetz, syzkaller

On Tue, Feb 28, 2017 at 4:42 PM, Andrea Arcangeli <aarcange@redhat.com> wrote:
> Hello Dmitry,
>
> On Tue, Feb 28, 2017 at 03:04:53PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers GPF in __do_fault:
>> https://gist.githubusercontent.com/dvyukov/27345737fca18d92ef761e7fa08aec9b/raw/d99d02511d0bf9a8d6f6bd9c79d373a26924e974/gistfile1.txt
>
> Can you verify this fix:


Applied the patch on bots.


> From a65381bc86d2963713b6a9c4a73cded7dd184282 Mon Sep 17 00:00:00 2001
> From: Andrea Arcangeli <aarcange@redhat.com>
> Date: Tue, 28 Feb 2017 16:36:59 +0100
> Subject: [PATCH 1/1] userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE
>
> __do_fault assumes vmf->page has been initialized and is valid if
> VM_FAULT_NOPAGE is not returned by vma->vm_ops->fault(vma, vmf).
>
> handle_userfault() in turn should return VM_FAULT_NOPAGE if it doesn't
> return VM_FAULT_SIGBUS or VM_FAULT_RETRY (the other two
> possibilities).
>
> This VM_FAULT_NOPAGE case is only invoked when signal are pending and
> it didn't matter for anonymous memory before. It only started to
> matter since shmem was introduced. hugetlbfs also takes a different
> path and doesn't exercise __do_fault.
>
> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
> ---
>  fs/userfaultfd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index fb6d02b..de28f43 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -500,7 +500,7 @@ int handle_userfault(struct vm_fault *vmf, unsigned long reason)
>                          * in such case.
>                          */
>                         down_read(&mm->mmap_sem);
> -                       ret = 0;
> +                       ret = VM_FAULT_NOPAGE;
>                 }
>         }
>
>
> --
> 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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-03-03  7:42 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-28 14:04 mm: fault in __do_fault Dmitry Vyukov
2017-02-28 15:32 ` Kirill A. Shutemov
2017-02-28 15:55   ` Andrea Arcangeli
2017-02-28 15:42 ` Andrea Arcangeli
2017-03-03  7:42   ` Dmitry Vyukov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).