From mboxrd@z Thu Jan 1 00:00:00 1970 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 60341E7719A for ; Fri, 10 Jan 2025 02:32:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EBC096B009C; Thu, 9 Jan 2025 21:32:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E6B216B009E; Thu, 9 Jan 2025 21:32:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5A276B00A2; Thu, 9 Jan 2025 21:32:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B918F6B009C for ; Thu, 9 Jan 2025 21:32:25 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 384A11C7327 for ; Fri, 10 Jan 2025 02:32:25 +0000 (UTC) X-FDA: 82989968250.04.E669A0B Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf12.hostedemail.com (Postfix) with ESMTP id B120B40003 for ; Fri, 10 Jan 2025 02:32:22 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf12.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=liushixin2@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736476343; a=rsa-sha256; cv=none; b=fyzgDihCGuJoGk31oEIaKz0clEsZU1RbWVOiIn208Pjqgf0cDpaQdkDZsFVjUHW4YzuaRj /Z4NIfjAZvL5MY2Ob0BjVqMtF93sj8F+4WRkXj7I6flEyPzbTGOcEh/vUmH1HDYDCqzVFD LmOLfGlhVN2JiMsDEyivlJ9KfhhDxgE= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf12.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=liushixin2@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736476343; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=052lHhvinII6FQVqNLyC+eIwXuT6vl5VgqVJCeY7sV4=; b=JlVGRga6YYnmOr4+BT56UNbXDkFgO3wlgd4iH1IhV0jF5xh5mF+1GcJY1od4vHmx4E16BI geknT6Yg21MdOQKtUOewULt0dhOzqQjvlBd1PCLqIKU4nVtfyTUx4JyGamlc3Dyzr14cOX m5E/B0sVn8Jwm+wr+no8OUSYguhO6Vw= Received: from mail.maildlp.com (unknown [172.19.162.254]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4YTlvQ0L1Dz1W3t2; Fri, 10 Jan 2025 10:28:34 +0800 (CST) Received: from kwepemg200013.china.huawei.com (unknown [7.202.181.64]) by mail.maildlp.com (Postfix) with ESMTPS id F1CE0180105; Fri, 10 Jan 2025 10:32:17 +0800 (CST) Received: from [10.174.179.24] (10.174.179.24) by kwepemg200013.china.huawei.com (7.202.181.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 10 Jan 2025 10:32:16 +0800 Subject: Re: [PATCH] mm: khugepaged: fix call hpage_collapse_scan_file() for anonymous vma To: Yang Shi , Andrew Morton , Chengming Zhou , Matthew Wilcox , Kefeng Wang , Nanyong Sun , Muchun Song , Qi Zheng , Johannes Weiner References: <20250109070059.369257-1-liushixin2@huawei.com> <037d4442-4d2d-4aeb-8091-5efffc374d36@os.amperecomputing.com> CC: , From: Liu Shixin Message-ID: <3777bc2f-81d3-1372-e890-0ac352cc2ade@huawei.com> Date: Fri, 10 Jan 2025 10:32:16 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <037d4442-4d2d-4aeb-8091-5efffc374d36@os.amperecomputing.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemg200013.china.huawei.com (7.202.181.64) X-Stat-Signature: 4xijam46iywpmypx34fbyyjuai7upyao X-Rspam-User: X-Rspamd-Queue-Id: B120B40003 X-Rspamd-Server: rspam08 X-HE-Tag: 1736476342-159009 X-HE-Meta: U2FsdGVkX1+WYUrmzA5ud/DHAl6bFNumM1zBEJQwQrk26LSGZlZXDkDu5X18JNwcFuQhLw4B7Afly62y3Ef6w1PeEklZJwDZ4LttpmbVLwBKHgM+ZWcsxmNAySPMPqRbok0RCNaPlrHaeaXin1QxjQn7eNH92ZmQP1wgqlwN/rPsyjs9iKIN2Ptu0ztYvpSbJr633OzbBqjGhW5jKCS6fwxiYz1InhpmiatWBUcvyyY/2lScvjfvHChhXQpb7dXRHZAGGlFfUfd3GZdY2H1jrnmaccf+JCq7vnx4lbXfzaetCZ431dM7+vKcz2t2uE1s88bKRc3WSXs9r/SVrhn1nGnPcGPwQQB/b6olJLpOvvbTxWiMw6KS753SYEG0CoVJLHVR6tsHbbF5zhJ3khZ6LwgracpqQpvL6jS/Dra3VQ+CsvihkOZn8lpBgA8G5nb+YGbNmKNdqP/ML7Ib82ZF11JMqmuUsOW89iCAR3Mha9YyoemXgicSsRjlNtynaX8vI/G8iRkgS0jGrl0ddxSjgnGeMoAZ8fh9XI4Uz3Psh9PpkZ1s1SrsgxtoDfC8E45I4taiHnej246xYwn6nRjRrwhGq4fBRoTetVw/4/569cwcaD893FpnjOskSk8Qcsi+R2uhTi/rLSYTza8R4ag0/BsD3ReyJbPL3RYixf9ZrLBsnnfeqshlt0G7SdIOUww10mBqqTKRjD69S0ore7U+EXS3Yc9iti8Zc7fVj8cCN8ohP9ZM2GwdKyj7i/YOvSr/iD9retEpLETrz8vAbbK4JjgrWy/z+saxo8EFIcy1ebYvqbWx+m1rGbnWm9K2auGyY2qWhW2PYbNl0RUT/o1+NyG/+hG9x5SrALNM0iR8RWvlgHhseqeTLawJHHoJeYXw+ooOLi0md9qcvq/C/v2lhkwCoER/yu+/l1G0ndVhEc3EiK3Ndr21v1pPVCsP696xUg7YC7Q6uT2QtBGQ5es V24UxUU9 XzAKdSUuBJTFw7VXKCFlZUqVdtYLDkc/TBeCRtpqjC1JKTteyNLLg2dgDkH5OyzuJiE3nxjieVoJqBPwnUxr12qrN9g2ITEj0Z/UNB34EDHcc8kz3UEamrSn90fvvxvNzf+0uWoiLNU8CgAYRXUAYrYn48KfovyH6BCFahRVUJA/B8DdxyQ/ttHMWJnRGpgR/KcolQw4QwLEnAK4= 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: List-Subscribe: List-Unsubscribe: On 2025/1/10 1:00, Yang Shi wrote: > > > > On 1/8/25 11:00 PM, Liu Shixin wrote: >> syzkaller reported such a BUG_ON(): >> >> ------------[ cut here ]------------ >> kernel BUG at mm/khugepaged.c:1835! >> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP >> ... >> CPU: 6 UID: 0 PID: 8009 Comm: syz.15.106 Kdump: loaded Tainted: G W 6.13.0-rc6 #22 >> Tainted: [W]=WARN >> Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 >> pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) >> pc : collapse_file+0xa44/0x1400 >> lr : collapse_file+0x88/0x1400 >> sp : ffff80008afe3a60 >> ... >> Call trace: >> collapse_file+0xa44/0x1400 (P) >> hpage_collapse_scan_file+0x278/0x400 >> madvise_collapse+0x1bc/0x678 >> madvise_vma_behavior+0x32c/0x448 >> madvise_walk_vmas.constprop.0+0xbc/0x140 >> do_madvise.part.0+0xdc/0x2c8 >> __arm64_sys_madvise+0x68/0x88 >> invoke_syscall+0x50/0x120 >> el0_svc_common.constprop.0+0xc8/0xf0 >> do_el0_svc+0x24/0x38 >> el0_svc+0x34/0x128 >> el0t_64_sync_handler+0xc8/0xd0 >> el0t_64_sync+0x190/0x198 >> >> This indicates that the pgoff is unaligned. After analysis, I confirm >> the vma is mapped to /dev/zero. Such a vma certainly has vm_file, but >> it is set to anonymous by mmap_zero(). So even if it's mmapped by >> 2m-unaligned, it can pass the check in thp_vma_allowable_order() as it >> is an anonymous-mmap, but then be collapsed as a file-mmap. >> >> It seems the problem has existed for a long time, but actually, since >> we have khugepaged_max_ptes_none check before, we will skip collapse it >> as it is /dev/zero and so has no present page. But commit d8ea7cc8547c >> limit the check for only khugepaged, so the BUG_ON() can be triggered >> by madvise_collapse(). >> >> Add vma_is_anonymous() check to make such vma be processed by >> hpage_collapse_scan_pmd(). >> >> Fixes: d8ea7cc8547c ("mm/khugepaged: add flag to predicate khugepaged-only behavior") >> Signed-off-by: Liu Shixin >> --- >> mm/khugepaged.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/mm/khugepaged.c b/mm/khugepaged.c >> index 653dbb1ff05c..eb9d240e42e8 100644 >> --- a/mm/khugepaged.c >> +++ b/mm/khugepaged.c >> @@ -2422,7 +2422,8 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result, >> VM_BUG_ON(khugepaged_scan.address < hstart || >> khugepaged_scan.address + HPAGE_PMD_SIZE > >> hend); >> - if (IS_ENABLED(CONFIG_SHMEM) && vma->vm_file) { >> + if (IS_ENABLED(CONFIG_SHMEM) && vma->vm_file && >> + !vma_is_anonymous(vma)) { > > Thanks for catching this. It sounds a little bit weird to have vm_file for an anonymous VMA. I'm not sure why we should keep such special case. It seems shared mapping is treated as shmem file mapping. So can we set vm_file to NULL when mmap'ing /dev/zero for private mapping? Something like: > > diff --git a/drivers/char/mem.c b/drivers/char/mem.c > index 169eed162a7f..fc332efc5c11 100644 > --- a/drivers/char/mem.c > +++ b/drivers/char/mem.c > @@ -527,6 +527,7 @@ static int mmap_zero(struct file *file, struct vm_area_struct *vma) > if (vma->vm_flags & VM_SHARED) > return shmem_zero_setup(vma); > vma_set_anonymous(vma); > + vma->vm_file = NULL; > return 0; > } > Thanks for your advise, I'll look at it again.