From patchwork Wed Sep 14 16:22:20 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yang Shi X-Patchwork-Id: 12976357 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6BC2ECAAD3 for ; Wed, 14 Sep 2022 16:22:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3871C8D0002; Wed, 14 Sep 2022 12:22:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 337188D0001; Wed, 14 Sep 2022 12:22:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FF6D8D0002; Wed, 14 Sep 2022 12:22:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1366E8D0001 for ; Wed, 14 Sep 2022 12:22:25 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id DCA2740AAC for ; Wed, 14 Sep 2022 16:22:24 +0000 (UTC) X-FDA: 79911208608.17.8B56FC9 Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by imf04.hostedemail.com (Postfix) with ESMTP id 8D2A4400A5 for ; Wed, 14 Sep 2022 16:22:24 +0000 (UTC) Received: by mail-pg1-f175.google.com with SMTP id r23so6187000pgr.6 for ; Wed, 14 Sep 2022 09:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date; bh=QqY6zjkG7tOexQ+JjAZx9uwGMUGEwBPtZu3WWvYMDno=; b=Js3JLJVwxW6aPUc2ShK4wv7Asbdt/viVK7yBFmCA7Vzi1h3NRWCV1b7+pyzu1ocgmi yaoBZI6v+7FFkWivhycjh6Cb8zBuStOeDQtVo12O6qXycIKRrH61iDc999xoQCKv4ZMp +j/KiKsQmDrhQvhvHcQUpu401lXswdiVtRewqoIWdWFmKCQaQL9nnQBeVMkcysPB2HQ3 LJOPWpgPO92uKaXam6YL1J1OOEI19DYABLjUs+5xPv9mTMCXXkcb3yOs8jJ13/YoXxZy KykZzSLXXKPoffLpARaqo8eJAQtxyrqNSsJmC73ochewSEbMgANHABlEDIA7jllBFbgH KSSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date; bh=QqY6zjkG7tOexQ+JjAZx9uwGMUGEwBPtZu3WWvYMDno=; b=nXi0gAPzEgK4Q5XzYBH9yg1CdrTolYcYR3xfoXeeHqqlLde6cynQs42wHWTSv7U6Ej TzolAH4286UGHQAf2D5SsuT5FtVe6kOxAemfZYkhcG64VBYFbwSiUef/yhpsRkjcihTT fxZcL605LykwliT8+ID2plfpib3qEMWFRqPx4NnLcEqAQMGqoaR/4ZYmXr95lGjPywwf 51I9GosvouJeNvDylVveu65MxT1A0Tis7qzlBssmCPy5SN4zffcehl98tqOAoPqMHhVk J00hmH2EZAy3F7EbNc8JE2pMUNh0NGiUVXlDpNsIh+cjoyCVtXgF8CVpoGTxaTJSq934 yJTw== X-Gm-Message-State: ACgBeo0hgTb2Wqw1rPDcGDrc9bK2cXR/7P+z8ohc9HWgdJV2yg+CBF0f w/YqwgxZ7MdvrDuSxgMdgOGKPKrmn9k= X-Google-Smtp-Source: AA6agR4X81GW/E4KDjaiut+rqrYIpZEF2/pQBOVAZbFy5EboxvbT4KLIY1sfWf8sZQMQouCyKpsliQ== X-Received: by 2002:a63:5244:0:b0:434:a3b1:bbe8 with SMTP id s4-20020a635244000000b00434a3b1bbe8mr33036980pgl.57.1663172543519; Wed, 14 Sep 2022 09:22:23 -0700 (PDT) Received: from localhost.localdomain (c-67-174-241-145.hsd1.ca.comcast.net. [67.174.241.145]) by smtp.gmail.com with ESMTPSA id ik22-20020a170902ab1600b0016dc26c7d30sm5777187plb.164.2022.09.14.09.22.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Sep 2022 09:22:22 -0700 (PDT) From: Yang Shi To: zokeefe@google.com, akpm@linux-foundation.org Cc: shy828301@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [mm-unstable PATCH] mm: MADV_COLLAPSE: refetch vm_end after reacquiring mmap_lock Date: Wed, 14 Sep 2022 09:22:20 -0700 Message-Id: <20220914162220.787703-1-shy828301@gmail.com> X-Mailer: git-send-email 2.26.3 MIME-Version: 1.0 ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Js3JLJVw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.175 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663172544; a=rsa-sha256; cv=none; b=03HZXXySrZNuxi+wFJwC7raE/LMkEjyolVfGCiwyAKNRU6vufgIxbrn2R2XOeN1B8q64Xe 2WAGbjsS3cLG370gVUWsJBWG20drHSDi6eW+6MlQ//SVlXlgh9JBgyxWjN23x7UknEGyt+ C2n22ZhLHjVGHxCWcpG0fIS0LoVfPcU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663172544; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=QqY6zjkG7tOexQ+JjAZx9uwGMUGEwBPtZu3WWvYMDno=; b=KvOOrvc8kA6b2yZ6h3IsYmTWywuvtGJ0Sxdz/jL4g7yONvLawYi0sYDHu9Kjzy/yrySzkv wJ1pEvx2vBVxZwtdmr5S1Xe0zoQZCR8ltLCdhyCKjHTskEHDp4OiGdpnM1KfaSupdIQYah JZaKaoqhWOjUQkX51XmHRutU2Xv5m30= X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Js3JLJVw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.175 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8D2A4400A5 X-Stat-Signature: jatc618mn3u8x7wergb7rnuw1757fbox X-HE-Tag: 1663172544-875525 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: The syzbot reported the below problem: BUG: Bad page map in process syz-executor198 pte:8000000071c00227 pmd:74b30067 addr:0000000020563000 vm_flags:08100077 anon_vma:ffff8880547d2200 mapping:0000000000000000 index:20563 file:(null) fault:0x0 mmap:0x0 read_folio:0x0 CPU: 1 PID: 3614 Comm: syz-executor198 Not tainted 6.0.0-rc3-next-20220901-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_bad_pte.cold+0x2a7/0x2d0 mm/memory.c:565 vm_normal_page+0x10c/0x2a0 mm/memory.c:636 hpage_collapse_scan_pmd+0x729/0x1da0 mm/khugepaged.c:1199 madvise_collapse+0x481/0x910 mm/khugepaged.c:2433 madvise_vma_behavior+0xd0a/0x1cc0 mm/madvise.c:1062 madvise_walk_vmas+0x1c7/0x2b0 mm/madvise.c:1236 do_madvise.part.0+0x24a/0x340 mm/madvise.c:1415 do_madvise mm/madvise.c:1428 [inline] __do_sys_madvise mm/madvise.c:1428 [inline] __se_sys_madvise mm/madvise.c:1426 [inline] __x64_sys_madvise+0x113/0x150 mm/madvise.c:1426 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f770ba87929 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 11 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f770ba18308 EFLAGS: 00000246 ORIG_RAX: 000000000000001c RAX: ffffffffffffffda RBX: 00007f770bb0f3f8 RCX: 00007f770ba87929 RDX: 0000000000000019 RSI: 0000000000600003 RDI: 0000000020000000 RBP: 00007f770bb0f3f0 R08: 00007f770ba18700 R09: 0000000000000000 R10: 00007f770ba18700 R11: 0000000000000246 R12: 00007f770bb0f3fc R13: 00007ffc2d8b62ef R14: 00007f770ba18400 R15: 0000000000022000 Basically the test program does the below conceptually: 1. mmap 0x2000000 - 0x21000000 as anonymous region 2. mmap io_uring SQ stuff at 0x20563000 with MAP_FIXED, io_uring_mmap() actually remaps the pages with special PTEs 3. call MADV_COLLAPSE for 0x20000000 - 0x21000000 It actually triggered the below race: CPU A CPU B mmap 0x20000000 - 0x21000000 as anon madvise_collapse is called on this area Retrieve start and end address from the vma (NEVER updated later!) Collapsed the first 2M area and dropped mmap_lock Acquire mmap_lock mmap io_uring file at 0x20563000 Release mmap_lock Reacquire mmap_lock revalidate vma pass since 0x20200000 + 0x200000 > 0x20563000 scan the next 2M (0x20200000 - 0x20400000), but due to whatever reason it didn't release mmap_lock scan the 3rd 2M area (start from 0x20400000) get into the vma created by io_uring The hend should be updated after MADV_COLLAPSE reacquire mmap_lock since the vma may be shrunk. We don't have to worry about shink from the other direction since it could be caught by hugepage_vma_revalidate(). Either no valid vma is found or the vma doesn't fit anymore. Reported-by: syzbot+915f3e317adb0e85835f@syzkaller.appspotmail.com Signed-off-by: Yang Shi Reviewed-by: Zach O'Keefe --- mm/khugepaged.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/khugepaged.c b/mm/khugepaged.c index a3acd3e5e0f3..1860be232a26 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -2592,6 +2592,8 @@ int madvise_collapse(struct vm_area_struct *vma, struct vm_area_struct **prev, last_fail = result; goto out_nolock; } + + hend = vma->vm_end & HPAGE_PMD_MASK; } mmap_assert_locked(mm); memset(cc->node_load, 0, sizeof(cc->node_load));