All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Song Liu <songliubraving@fb.com>
Cc: Hillf Danton <hdanton@sina.com>,
	syzbot <syzbot+ed318e8b790ca72c5ad0@syzkaller.appspotmail.com>,
	open list <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	"syzkaller-bugs@googlegroups.com"
	<syzkaller-bugs@googlegroups.com>,
	Markus Elfring <Markus.Elfring@web.de>
Subject: Re: general protection fault in khugepaged
Date: Fri, 24 Jul 2020 14:06:51 +0300	[thread overview]
Message-ID: <20200724110651.6yvcpse4emi2bdrm@box> (raw)
In-Reply-To: <27C67962-55A0-4815-ABE3-7F71C5FDCE4D@fb.com>

On Wed, Jul 22, 2020 at 11:53:11PM +0000, Song Liu wrote:
> 
> 
> > On Jul 20, 2020, at 2:08 AM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
> > 
> > On Sat, Jul 18, 2020 at 04:54:09PM +0800, Hillf Danton wrote:
> >> 
> >> Wed, 08 Jul 2020 23:43:19 -0700
> >>> syzbot found the following crash on:
> >>> 
> >>> HEAD commit:    e44f65fd xen-netfront: remove redundant assignment to vari..
> >>> git tree:       net-next
> >>> console output: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_log.txt-3Fx-3D15de54a7100000&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=dR8692q0_uaizy0jkrBJQM5k2hfm4CiFxYT8KaysFrg&m=MQfhDjE9yj2_juw34scN2XTASkKaxHCfKtrY5UlwTx4&s=6MfBZJE4yUynBic_FV4udh1WdM1wXz8vdcsOfuR23y0&e= 
> >>> kernel config:  https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_.config-3Fx-3D829871134ca5e230&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=dR8692q0_uaizy0jkrBJQM5k2hfm4CiFxYT8KaysFrg&m=MQfhDjE9yj2_juw34scN2XTASkKaxHCfKtrY5UlwTx4&s=KvhWD3PT9mC8iTIUtQGrMj2UJpBMlsmJOv_wx1kxkQQ&e= 
> >>> dashboard link: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_bug-3Fextid-3Ded318e8b790ca72c5ad0&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=dR8692q0_uaizy0jkrBJQM5k2hfm4CiFxYT8KaysFrg&m=MQfhDjE9yj2_juw34scN2XTASkKaxHCfKtrY5UlwTx4&s=sLoGzpV5UcRyP33XaPaGp_NoxP6VSXh4jttnxne6n6I&e= 
> >>> compiler:       gcc (GCC) 10.1.0-syz 20200507
> >>> syz repro:      https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_repro.syz-3Fx-3D113406a7100000&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=dR8692q0_uaizy0jkrBJQM5k2hfm4CiFxYT8KaysFrg&m=MQfhDjE9yj2_juw34scN2XTASkKaxHCfKtrY5UlwTx4&s=HXYlOJ8r_Xv84UDkW6MSoEiG122ATfKJdhQlv3J7mao&e= 
> >>> C reproducer:   https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_repro.c-3Fx-3D175597d3100000&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=dR8692q0_uaizy0jkrBJQM5k2hfm4CiFxYT8KaysFrg&m=MQfhDjE9yj2_juw34scN2XTASkKaxHCfKtrY5UlwTx4&s=c5Vlm43NNztzFCNb0S6s8IKJuVUtEtm0yWwfV55CeAo&e= 
> >>> 
> >>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >>> Reported-by: syzbot+ed318e8b790ca72c5ad0@syzkaller.appspotmail.com
> >>> 
> >>> general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
> >>> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> >>> CPU: 1 PID: 1155 Comm: khugepaged Not tainted 5.8.0-rc2-syzkaller #0
> >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> >>> RIP: 0010:anon_vma_lock_write include/linux/rmap.h:120 [inline]
> >>> RIP: 0010:collapse_huge_page mm/khugepaged.c:1110 [inline]
> >>> RIP: 0010:khugepaged_scan_pmd mm/khugepaged.c:1349 [inline]
> >>> RIP: 0010:khugepaged_scan_mm_slot mm/khugepaged.c:2110 [inline]
> >>> RIP: 0010:khugepaged_do_scan mm/khugepaged.c:2193 [inline]
> >>> RIP: 0010:khugepaged+0x3bba/0x5a10 mm/khugepaged.c:2238
> >>> Code: 01 00 00 48 8d bb 88 00 00 00 48 89 f8 48 c1 e8 03 42 80 3c 30 00 0f 85 fa 0f 00 00 48 8b 9b 88 00 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 0f 85 d4 0f 00 00 48 8b 3b 48 83 c7 08 e8 9f ff 30
> >>> RSP: 0018:ffffc90004be7c80 EFLAGS: 00010246
> >>> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff81a72d8b
> >>> RDX: ffff8880a69d8100 RSI: ffffffff81b7606b RDI: ffff88809f0577c0
> >>> RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881ff213a7f
> >>> R10: 0000000000000080 R11: 0000000000000000 R12: ffffffff8aae6110
> >>> R13: ffffc90004be7de0 R14: dffffc0000000000 R15: 0000000020000000
> >>> FS:  0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
> >>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >>> CR2: 0000000000000000 CR3: 00000001fe0cf000 CR4: 00000000001406e0
> >>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> >>> Call Trace:
> >>> kthread+0x3b5/0x4a0 kernel/kthread.c:291
> >>> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
> >> 
> >> Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS")
> > 
> > It looks sane, but I think it's easier to check in
> > hugepage_vma_revalidate(). Something like this (untested):
> > 
> > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > index b043c40a21d4..700f5160f3e4 100644
> > --- a/mm/khugepaged.c
> > +++ b/mm/khugepaged.c
> > @@ -958,6 +958,9 @@ static int hugepage_vma_revalidate(struct mm_struct *mm, unsigned long address,
> > 		return SCAN_ADDRESS_RANGE;
> > 	if (!hugepage_vma_check(vma, vma->vm_flags))
> > 		return SCAN_VMA_CHECK;
> > +	/* Anon VMA expected */
> > +	if (!vma->anon_vma || vma->vm_ops)
> > +		return SCAN_VMA_CHECK;
> > 	return 0;
> > }
> 
> Maybe move the new check to earlier in the function, say right after 
> we get the vma? 

Maybe. But we only protect against the race and it's not going to make a
difference for performance.

-- 
 Kirill A. Shutemov


      reply	other threads:[~2020-07-24 11:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09  6:43 general protection fault in khugepaged syzbot
2020-07-17 22:40 ` syzbot
2020-07-17 23:10   ` Kirill A. Shutemov
2020-07-18  8:54 ` Hillf Danton
2020-07-20  9:08   ` Kirill A. Shutemov
2020-07-22 23:53     ` Song Liu
2020-07-24 11:06       ` Kirill A. Shutemov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200724110651.6yvcpse4emi2bdrm@box \
    --to=kirill@shutemov.name \
    --cc=Markus.Elfring@web.de \
    --cc=hdanton@sina.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=songliubraving@fb.com \
    --cc=syzbot+ed318e8b790ca72c5ad0@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.