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 EB044C27C78 for ; Wed, 12 Jun 2024 02:41:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 59CC16B0138; Tue, 11 Jun 2024 22:41:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 54C356B013A; Tue, 11 Jun 2024 22:41:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 414A56B013B; Tue, 11 Jun 2024 22:41:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 237096B0138 for ; Tue, 11 Jun 2024 22:41:36 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8656C140729 for ; Wed, 12 Jun 2024 02:41:35 +0000 (UTC) X-FDA: 82220685750.21.4A6D6F0 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf26.hostedemail.com (Postfix) with ESMTP id 71CFA14000D for ; Wed, 12 Jun 2024 02:41:32 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718160093; 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=ZLcYbMvw7TL/0ga0uTRvy2J22vJyxz2bDdQ6CLuOlfA=; b=QKLP+I/+NLUtWwbFSUihPKS4EPci48d3Ymfe3W75C/Fz7D2q2h85AGdFrVD3BJMGsVd1mi Lu7A4KczJSEUnW6Tw6cL//tmiOCqREV1upCdAqQXjXt1llltmknXhk4Q6jqCtfFj6/cGGY pbUbY/elDmkBoUewlkrVZWkC8yVUvT0= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718160093; a=rsa-sha256; cv=none; b=I40NmVatjq6SE1bUcMG7bz0uHCgiNCtKRajQm2hbqMrAQ2x6lkbtj4okeQ+jOYpgU0Z9HA K0xPQBWJDmCB1XF5cCjOY8pCC+5PzCoPEuYlT87IC7VZrcYT4+jVP3WYzvYeW8cR0icImQ 6rsNFZi41Cy2ksAtHGNzQ9rs+ohjASM= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4VzV7S0jw7zxSdf; Wed, 12 Jun 2024 10:37:24 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 2E9B018007E; Wed, 12 Jun 2024 10:41:28 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 12 Jun 2024 10:41:27 +0800 Message-ID: <1a916695-b503-4b1c-9869-7c358a31c762@huawei.com> Date: Wed, 12 Jun 2024 10:41:27 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Kefeng Wang Subject: Re: [PATCH] mm: fix possible OOB in numa_rebuild_large_mapping() To: David Hildenbrand , Andrew Morton , Baolin Wang CC: , , John Hubbard , Mel Gorman , Ryan Roberts , References: <20240607103241.1298388-1-wangkefeng.wang@huawei.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 71CFA14000D X-Stat-Signature: ari4dhe7916gtdfw8nw3ntpbh6r4q7fw X-HE-Tag: 1718160092-265351 X-HE-Meta: U2FsdGVkX1/QlGRjM5+1spUDw/XT6R6P5eDgrRp32eBjTjUpTw7rdwY9w0a+LkCOJqZhTSwMUVbdNXeC/YgzfBoTD3Jk4TWm2pnxM8YBIk1oFg4HzSieXpfUfTGSNHcrFaQMyaECcBReAGJKHM8VW8GFL4BHVwo4lfgZ1xgxc28Aa1Kqub8cWZkysyoRfRIxLw0kpZkrcGPChR0qUrmm2/fizsGkqbYsBA9yAVvmHenUSRLBgSVt5PAAM9ebfHYyr7yZuvfWrRISEbahmgonxZM5j+ZIdvSwxtR338V+c2xbbOKrHBntXVRQARHLtT7RJywse6uRP3RIHoHdoMvAMl70JijrCscRSPvQrguyhGtZXMljUDiTVKF3PejIPYOlFcjNIWDvhnBcpkezvKclfD7stcnu2V1EjtmC7YN3FSC+l8S88gJjFAcbenoICGr1uON36wWrcQTJQi2z/ZfU/mb+o1ugxx8h4CtlsDRAerrLn2jO5efuJmolFXE+zqvcuRadqgaMfud47DktlgOZ0DNyl8ag2TI1qMlxpv9OQxfCjeqg1+FSypuymc56lXjlXQIy+tRb/w44jT3X2kpltniSTglWSdNL5A/Rdq3qesNk4yPofIPx/DQBe6aCeP4ZjdUT/AzfBmuDp8KRJBswkNlqGtGu+Fgnn6PhMu4NiND4iFZkQRDgoBPdvI4k/wqavS0lMV94RXAWqfG8f0v9rwAXjFj5L7fNP6d+elHy1yqINIDh8JczLhPTxYfcl411KnNNlnj/qmOCEZXdckAgvWVWyfUMLfPpDO/RBoFgq7IiSgKAqlfrhgmOK7DX3ybWAPmhbgt28Ncj6p+beY/epivn0WPRjMxs017X9a2q25lTjSPvU29go5Nym4zuzUe6lnqnTePIlARGP7Bh6tRi8gT0U1p5/8vweltDfwoGbuSxm2R4GrCBlG3pliOHe3hFKjk4ehI4tVTMA01LezR 0H4eDG7Z tNpEkHIerCUrB2sPwGagRqj1K4Nag95GmmlTjkMzFfkkyGA57kKk2zn5nMnG8sHlmcC7Dz+Wkh679+wv2F/rIHu57rTwul5/Iq30FZ6Iqvnc3FPBIl9Cao0rLwES6kaC1rWBEMea7MwD+HwVZLwO2qIBMb3mwHB0jCRsWLXLTwFxLmv2fRwoFCm3JEQpZao/BPTyIvXIr0xXHzjgccxfYpZINkANSIkKp2saSIhxNo2BBqJBf5ITMCC/vHw== 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: Hi David and Baolin, On 2024/6/7 18:37, David Hildenbrand wrote: > On 07.06.24 12:32, Kefeng Wang wrote: >> The large folio is mapped with folio size aligned virtual address during >> the pagefault, eg, 'addr = ALIGN_DOWN(vmf->address, nr_pages * >> PAGE_SIZE)' >> in do_anonymous_page(), but after the mremap(), the virtual address only >> require PAGE_SIZE aligned, also pte is moved to new in >> move_page_tables(), >> then traverse the new pte in numa_rebuild_large_mapping() will hint the >> following issue, >> >>     Unable to handle kernel paging request at virtual address >> 00000a80c021a788 >>     Mem abort info: >>       ESR = 0x0000000096000004 >>       EC = 0x25: DABT (current EL), IL = 32 bits >>       SET = 0, FnV = 0 >>       EA = 0, S1PTW = 0 >>       FSC = 0x04: level 0 translation fault >>     Data abort info: >>       ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 >>       CM = 0, WnR = 0, TnD = 0, TagAccess = 0 >>       GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 >>     user pgtable: 4k pages, 48-bit VAs, pgdp=00002040341a6000 >>     [00000a80c021a788] pgd=0000000000000000, p4d=0000000000000000 >>     Internal error: Oops: 0000000096000004 [#1] SMP >>     ... >>     CPU: 76 PID: 15187 Comm: git Kdump: loaded Tainted: G >> W          6.10.0-rc2+ #209 >>     Hardware name: Huawei TaiShan 2280 V2/BC82AMDD, BIOS 1.79 08/21/2021 >>     pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) >>     pc : numa_rebuild_large_mapping+0x338/0x638 >>     lr : numa_rebuild_large_mapping+0x320/0x638 >>     sp : ffff8000b41c3b00 >>     x29: ffff8000b41c3b30 x28: ffff8000812a0000 x27: 00000000000a8000 >>     x26: 00000000000000a8 x25: 0010000000000001 x24: ffff20401c7170f0 >>     x23: 0000ffff33a1e000 x22: 0000ffff33a76000 x21: ffff20400869eca0 >>     x20: 0000ffff33976000 x19: 00000000000000a8 x18: ffffffffffffffff >>     x17: 0000000000000000 x16: 0000000000000020 x15: ffff8000b41c36a8 >>     x14: 0000000000000000 x13: 205d373831353154 x12: 5b5d333331363732 >>     x11: 000000000011ff78 x10: 000000000011ff10 x9 : ffff800080273f30 >>     x8 : 000000320400869e x7 : c0000000ffffd87f x6 : 00000000001e6ba8 >>     x5 : ffff206f3fb5af88 x4 : 0000000000000000 x3 : 0000000000000000 >>     x2 : 0000000000000000 x1 : fffffdffc0000000 x0 : 00000a80c021a780 >>     Call trace: >>      numa_rebuild_large_mapping+0x338/0x638 >>      do_numa_page+0x3e4/0x4e0 >>      handle_pte_fault+0x1bc/0x238 >>      __handle_mm_fault+0x20c/0x400 >>      handle_mm_fault+0xa8/0x288 >>      do_page_fault+0x124/0x498 >>      do_translation_fault+0x54/0x80 >>      do_mem_abort+0x4c/0xa8 >>      el0_da+0x40/0x110 >>      el0t_64_sync_handler+0xe4/0x158 >>      el0t_64_sync+0x188/0x190 > > Do you have an easy reproducer that we can use to reproduce+verify this > issue? The description above indicates to me that this should not be too > complicated to write :) > Sorry for the late due to traditional Chinese festival, the issue is easily reproduced when enable mTHP but drop the "align larger anonymous mappings on THP boundaries" on arm64, here is the step, drop the align anon mapping on THP[Optional, but not very easy to reproduce] cd /sys/kernel/mm/transparent_hugepage/ echo never > hugepage-2048kB/never echo always > hugepage-1024kB/never (other size could reproduce issue too) git clone root@127.0.0.1:/home/git/linux (clone the local kernel repo) and in numa_rebuild_large_mapping(), we hint some different errors, but most are the bad access when if (pfn_folio(pte_pfn(ptent)) != folio) The page is invalid, so guess the ptent/start_ptep is wrong when traverse.