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 A35DFC3ABB2 for ; Wed, 28 May 2025 12:14:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 202A96B008C; Wed, 28 May 2025 08:14:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B3726B0092; Wed, 28 May 2025 08:14:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C9606B0093; Wed, 28 May 2025 08:14:21 -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 DF58B6B008C for ; Wed, 28 May 2025 08:14:20 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 363975C078 for ; Wed, 28 May 2025 12:14:20 +0000 (UTC) X-FDA: 83492209080.02.0090AEF Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf04.hostedemail.com (Postfix) with ESMTP id AAAE940003 for ; Wed, 28 May 2025 12:14:17 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf04.hostedemail.com: domain of tujinjiang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=tujinjiang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748434458; 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=yPKH0vVYBBJi4x1xsJHM6bblGvh4CC5ca6fFfOxy2/0=; b=30exaZpbooFE0RJZKx+5L9G9e/MwYCERAGZsxnghtsTCVkPXnaK/4ID0BHekWDCuqZsYbt Z/Z4RDJlWF+A0xdkfUvb4PFg0+2whfxkpsI4KnhhmVZitwnO3yoCBmUZRh7EfAxLhqJ3UV hICGp2srutOKBWaMvt17BEzICj5ksLc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748434458; a=rsa-sha256; cv=none; b=BdeHTJJ1Z6CZ4Qu/9/V20HevcSwvYW7uvqzAs4ZZrf430jCfJzOmzmupJ8AYM720/c4uB+ o7ls/fcbsAkTn9G3ko0L5yVTHBL3GIALPX36M/jcILqY0vvsaFnh+oihtymB8jBgmkvJO4 VbraBzeTSaCR0+E/s9yQKMWNlhSXtcQ= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf04.hostedemail.com: domain of tujinjiang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=tujinjiang@huawei.com Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4b6pL34Hf3ztRQQ; Wed, 28 May 2025 20:12:59 +0800 (CST) Received: from kwepemo200002.china.huawei.com (unknown [7.202.195.209]) by mail.maildlp.com (Postfix) with ESMTPS id DC59A180B61; Wed, 28 May 2025 20:14:13 +0800 (CST) Received: from [10.174.179.13] (10.174.179.13) by kwepemo200002.china.huawei.com (7.202.195.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 28 May 2025 20:14:13 +0800 Message-ID: <65632ba5-3412-9103-9027-2d3e709a5565@huawei.com> Date: Wed, 28 May 2025 20:14:12 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH] mm: fix COW mapping handing in generic_access_phys To: David Hildenbrand , , , , , , , CC: , , Peter Xu References: <20250528015617.302681-1-tujinjiang@huawei.com> <0d4f0180-52e6-47c9-b141-54e7e7c86880@redhat.com> From: Jinjiang Tu In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.13] X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemo200002.china.huawei.com (7.202.195.209) X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: AAAE940003 X-Stat-Signature: qi3taeidxjx7u4w8j1xsky9ykaaqe4o4 X-Rspam-User: X-HE-Tag: 1748434457-166360 X-HE-Meta: U2FsdGVkX1/Bqbai4uRQnwMRxLZIU0H7NvzUOomDPXeKP6Q2tUm1B0UD8OoqcDd59S0+mksjiq/OY8l3JgFGiWvFR7hCWy4WgTcAq2fXdxKMWUGsq1Sy3Slh0eoyaq8Q0Cznra7zgdqTFnggZS0diwP3OFSkPMEBTtk9CDWb3GM/4ugOBP2w7++oBdWgO55GCLvtj7GMtWPopkY/hhuXWeajgQTIYIDePkCJKSHEaCNfYTpJKHX40nu3YaAK870FeczIqylVLLN6kw27mj4ZCvkZlODZRmXT6wu1VGgM4nRD220+n+G2UifN2yid4+I9Ih2WWTYYvGNMCtO0W+LW9CI0c5BsFI81WvcAKmd8i6ysf8w1XVeHdYvyd6Mytx4vbhOVZpQZiy52a/cGgTK2UKPLHweLkIZRWkgi1/pXbNYNx7GVbVRKbb9EPnTDrVgk63AE+Wm6ivF6pGQqsTuNU1Mq2htOxiWR/FhXK+K5FPtUomUjBpKcIOhe3uzoj38bVooE2zQr7nodRzSaxuc+1jXuRuB+zpzgzDIMmCsNGonQosIelH/pAf5f7g1hp827/d294hVKmvedxbauheKNBrNXGWILJKp+BcpUULBVZGKNX2UtYnBdBvW0VhORODUQyaZQRgLCCLyMHLUIzKu3Ht6q3xwnDaQtsqTVZA2oalVmxTqzdwlvR/uPLDZ/okE2z0y6JhIua9+nyI08PuCvWMmc8o+Es68fHJlJJov24iJR7cDSOIjPd/dPTBaqecV25Sb9ReHNWvRGIKidcoAvUKcHOK89Vq51dd5EUwRwFsk/Q6oilWvm6cS+YrZTVUkND+fa6QgG1JIQAXd3rLMgwmtgraNkrqjPDc3aDkrvkQcCTVTwE8z8E/oCf8NNjOo4aE+648n5kz8y/f7UBYdvoKwnjaVgD281bhR5ENxKuiGDEbCzpQGxPXZFoWcoYUl54CqJFOp5shIybaTWI82 rhSxJwGp 9AUDsfTQd9Ps5OtleuX4FA3/e/J0isbWTtmqi+DwthOWSaM9XMQxa3/JTdLdupeYkTu5zKFaNi+EN8bB5c0Wx89CEkZGpaf7iFz8K7wni8YvEZDh1Cwrove4i4i6gLtMmihhm1FR67ycw5psbcrcPcHX4YkuaByy/O5FOSr5sPI6CYd4RkOyUmx7vdMWmTvpBEAH+SEtc9akb5RzAUfTR0FjLJHhu5jVWTZcCOcc5Tzmr5vo1CrzdbL3ryHk1e25+CHGhvDiOP2U4yZSvKw06WPpbNy4Au+PbyGh5pntVyU/lq2tPXE1JPtc5lqpjwaeMO+QK29IMBeMSDII= 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: 在 2025/5/28 17:59, David Hildenbrand 写道: > On 28.05.25 10:59, David Hildenbrand wrote: >> On 28.05.25 03:56, Jinjiang Tu wrote: >>> Syzkaller reports a below BUG: >>>    ioremap on RAM at 0x0000000022727000 - 0x0000000022727fff >>>    WARNING: CPU: 3 PID: 3609 at arch/x86/mm/ioremap.c:216 >>> __ioremap_caller+0x644/0x7f0 arch/x86/mm/ioremap.c:216 >>>    Modules linked in: >>>    CPU: 3 PID: 3609 Comm: syz.2.577 Not tainted 6.6.0+ #63 >>>    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >>> rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 >>>    RIP: 0010:__ioremap_caller+0x644/0x7f0 arch/x86/mm/ioremap.c:216 >>>    Call Trace: >>>     >>>     generic_access_phys+0x241/0x480 mm/memory.c:6458 >>>     __access_remote_vm+0x6af/0x970 mm/memory.c:6535 >>>     access_process_vm+0x53/0x80 mm/memory.c:6600 >>>     get_cmdline+0x192/0x380 mm/util.c:1041 >>>     audit_log_proctitle kernel/auditsc.c:1620 [inline] >>>     audit_log_exit+0x1424/0x18c0 kernel/auditsc.c:1811 >>>     __audit_syscall_exit+0x252/0x2f0 kernel/auditsc.c:2079 >>>     audit_syscall_exit include/linux/audit.h:356 [inline] >>>     syscall_exit_work+0x10f/0x130 kernel/entry/common.c:166 >>>     __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] >>>     syscall_exit_to_user_mode+0x10/0x1e0 kernel/entry/common.c:218 >>>     do_syscall_64+0x66/0x110 arch/x86/entry/common.c:87 >>>     entry_SYSCALL_64_after_hwframe+0x78/0xe2 >>> >>> The /dev/mem is mapped with COW mapping, and mremap at the >>> mm->args_start. >>> The special pfn mapping is replaced by anon folios due to COW. >>> generic_access_phys() is supposed to handle iomem, instead of RAM pfn, >>> thus trigger a WARN_ON. >>> >>> Similar to commit 04c35ab3bdae ("x86/mm/pat: fix VM_PAT handling in >>> COW mappings"). check if the pte is special to reject Cowed anon >>> folios. >>> >>> Signed-off-by: Jinjiang Tu >>> --- >>>    mm/memory.c | 7 +++++++ >>>    1 file changed, 7 insertions(+) >>> >>> diff --git a/mm/memory.c b/mm/memory.c >>> index 49199410805c..e1dac84536ee 100644 >>> --- a/mm/memory.c >>> +++ b/mm/memory.c >>> @@ -6840,6 +6840,13 @@ int generic_access_phys(struct vm_area_struct >>> *vma, unsigned long addr, >>>    retry: >>>        if (follow_pfnmap_start(&args)) >>>            return -EINVAL; >>> + >>> +    /* Never return PFNs of anon folios in COW mappings. */ >>> +    if (!args.special) { >>> +        follow_pfnmap_end(&args); >>> +        return -EINVAL; >>> +    } >>> + >>>        prot = args.pgprot; >>>        phys_addr = (resource_size_t)args.pfn << PAGE_SHIFT; >>>        writable = args.writable; >> >> I assume we trigger this through vma->vm_ops->access, when the vm_ops >> have generic_access_phys set. >> >> I still dislike exposing the "special" bit here, as it is absolutely >> not what we should care about in the caller. >> >> In case our arch does not support pte_special, you fix will not catch >> that case ... >> >> The following might be better: >> >> diff --git a/mm/memory.c b/mm/memory.c >> index 37d8738f5e12e..810adb8d1a53b 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -6681,6 +6681,14 @@ int generic_access_phys(struct vm_area_struct >> *vma, unsigned long addr, >>           prot = args.pgprot; >>           phys_addr = (resource_size_t)args.pfn << PAGE_SHIFT; >>           writable = args.writable; >> + >> +       /* Refuse (refcounted) anonymous pages in CoW mappings. */ >> +       if (is_cow_mapping(vma->vm_flags) && >> +           vm_normal_page(vma, addr, ptep_get(args.ptep))) { >> +               follow_pfnmap_end(&args); >> +               return -EINVAL; >> +       } >> + > > Thinking again, we might have a PMD/PUD mapping, so maybe > follow_pfnmap_start() should really just refuse any refcounted pages. Thanks for reviewing, I will investigate it.