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 3D721CCFA16 for ; Mon, 30 Sep 2024 19:03:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5746280021; Mon, 30 Sep 2024 15:03:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A067F280017; Mon, 30 Sep 2024 15:03:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83253280021; Mon, 30 Sep 2024 15:03:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5C457280017 for ; Mon, 30 Sep 2024 15:03:33 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F3531406A5 for ; Mon, 30 Sep 2024 19:03:32 +0000 (UTC) X-FDA: 82622328264.22.167CB07 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf02.hostedemail.com (Postfix) with ESMTP id 286C480003 for ; Mon, 30 Sep 2024 19:03:27 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b="K5tNn/1A"; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=Q7c6Cz3x; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf02.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; dmarc=pass (policy=reject) header.from=oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727722883; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=a7WvJyU+MxW1dLu8//PQEru+5TePYOUUKJNHyLKSjIY=; b=5w+qFzel4zjVomcckg76r8yPH/KWHFCnW53U0VZ5R2vG/taS+5orMSaMQ6pqt7ISjBGEXP f6bfxw4omhTHkX3w2GNwNpJ0o7hEPf0dce/C4ZQ1jj70e9YD/R6GK1/PLT4XTwk/Ylr3z2 6uv1Z02jbccVHOnbM85MHZ2tG97xBAs= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1727722883; a=rsa-sha256; cv=pass; b=QF2a1mcF5SPz3BNTUe2LKyv/mMsqG7QZRVBURlZodc5sdAhUBlLXEkISTTv/nujsCm9+cp brRn9IfnA2oA4uRH15Pna0yTkqW+t/pOkgGw1zOOhHGTZ78Z1r+NDqgOX6SB2NRdv50V/m /CjXuWdnWHxyVTZxEGDxu7ylz0bljlg= ARC-Authentication-Results: i=2; imf02.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b="K5tNn/1A"; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=Q7c6Cz3x; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf02.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; dmarc=pass (policy=reject) header.from=oracle.com Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 48UIuZst032356; Mon, 30 Sep 2024 19:03:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h= date:from:to:cc:subject:message-id:references:content-type :in-reply-to:mime-version; s=corp-2023-11-20; bh=a7WvJyU+MxW1dLu 8//PQEru+5TePYOUUKJNHyLKSjIY=; b=K5tNn/1Afan9zZN483dGsTfEJW7H79u 6jDYlqvrA/JfOK4ravy15IFkzSAXei2bs25zY6ryOTP3SdOPoRSbRCTHJo42uGOe g7ls4rH9DdHWQzPt2BwHVgzSfoKkENZ9Jl9/dRYIUAX/hZX6fNptNEgQXrJFmyA9 fUunSoYw0ZHj89hWNw094qP/QtdT8eMUII3vMO+gHNdt4ksP4qOR1OVnTuPRN08m XLhF4bWkH/Bf1YZ58vQO+9gmg/4XryvbxFs91FxTyHmzYK2zklyyjN9n8XYeDt+E b3TG1IamT/zmmrZfckqIY3epRuF6kB6a/KCiLoF2MJOjgojuQKdesQA== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 41x8d1c5s2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 30 Sep 2024 19:03:25 +0000 (GMT) Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 48UIVMg7026382; Mon, 30 Sep 2024 19:03:24 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2041.outbound.protection.outlook.com [104.47.55.41]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 41x886fqvr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 30 Sep 2024 19:03:24 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s0CTVT5KWs9Fkv38k2OtTwshEWFMjxpyFqK2j8j7Ihizay5+3oJVMRwWVuFigcpRIhuacnSrtdQwBoVRukIcXrkII4AtcqLtHZttNbz1P8/p4efl/qOhgsFdw3eHvKMd6kgWbXqUFqAd/O9nrmPAgk5t+Gtf+IAqS6arZ4d1HcuzYlcvYSfXi328AkMNpbmQbkqgYwewg6AZEiVyRd1YJuVhvKa+sMpSTMLwOlx8NJ55Nzf+wC5aUCUFjkNMyERnIYIccbrZo0QsUi4ecqHCDzyaUJTiWtgqoZhjElArDiQknPh25sj4K+RPlYpFGYqmko05aGn5sjwwA3v6PEKblQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=a7WvJyU+MxW1dLu8//PQEru+5TePYOUUKJNHyLKSjIY=; b=gM/ZYTGChuV5VqaqSI1hHtYDfqYBouv3HRR7EYBRR4AOiwwnMGaLprl7YStqh6ntz2WyyojakqKMF/xQefl33e6kOSAvK8t5auovFho80kV+LzB/IXn1wS9bg3dNXiDMa0MSggeZ5gjd3l+dDxs+EmIBK0CKk6qRBe2pK8zTHUwNzevAPEo1gsP5JqlP5Wm8GBsCKgN4KvjJO4Jehwt0Vh59I9olqtzJ23CqscDpJoq4syYmFqLM6LTIfpejONtkDUOSGkubvWQJY6zC3Hnh3rI37y9oyEwv4tgqJwYZUEAxMSqprWc07RNXVK8OaoO/g/Xh0/Ed1zzRgnzG6Iyt4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a7WvJyU+MxW1dLu8//PQEru+5TePYOUUKJNHyLKSjIY=; b=Q7c6Cz3xMQ7TeP/HUAN6wb1RwSmRtNXEfCvrIxxEjeEKtozDEP9pebdechCnZPMLTqpfWlT+ob845EN4Ouig4fWtk80C2D1lQERNHXYyEnLB51af4vqKsfxz6GQlZaib7qsP45yp7yzgiqp4U8zK7sg/VJC3Fr6QkbQAoeDE/A8= Received: from SJ0PR10MB5613.namprd10.prod.outlook.com (2603:10b6:a03:3d0::5) by MW4PR10MB5703.namprd10.prod.outlook.com (2603:10b6:303:18d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8026.15; Mon, 30 Sep 2024 19:03:03 +0000 Received: from SJ0PR10MB5613.namprd10.prod.outlook.com ([fe80::4239:cf6f:9caa:940e]) by SJ0PR10MB5613.namprd10.prod.outlook.com ([fe80::4239:cf6f:9caa:940e%5]) with mapi id 15.20.8026.014; Mon, 30 Sep 2024 19:03:03 +0000 Date: Mon, 30 Sep 2024 20:03:00 +0100 From: Lorenzo Stoakes To: "qiwu.chen" Cc: akpm@linux-foundation.org, Liam.Howlett@oracle.com, vbabka@suse.cz, linux-mm@kvack.org, "qiwu.chen" Subject: Re: [PATCH] mm: move get_vma_name() from procfs to mm tree Message-ID: References: <20240929093212.40449-1-qiwu.chen@transsion.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240929093212.40449-1-qiwu.chen@transsion.com> X-ClientProxiedBy: LO4P123CA0607.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:314::9) To SJ0PR10MB5613.namprd10.prod.outlook.com (2603:10b6:a03:3d0::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ0PR10MB5613:EE_|MW4PR10MB5703:EE_ X-MS-Office365-Filtering-Correlation-Id: bdcc838b-1787-4b08-3b2f-08dce18282c5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?W2XZHSLWX6qwHxuJt2Qe4NAH647oUfFGe0ALkQiHrmBSqIw3rovBW3BhKDFL?= =?us-ascii?Q?jt+ySaQxEXSoN2HqqRM7yvzzefbO4iXcazVrxDKtyGnolQK5ZXPk7QoQZ3Gg?= =?us-ascii?Q?STQMC6fVNUhbbgn6x1Ms+zXHAQoVq6Kd+6+BlSgHSnq8vY+85mDRtKQbj0SP?= =?us-ascii?Q?SbfpkWhsAb4IVkcKN0y0VN22NrJ9oJ7Z0hsCpFGyDlh/WFAoW1qti08otdZ+?= =?us-ascii?Q?r1oxvhrqQVoaF7/kFPiZnYQsWXEPD/Q4iyEAdUss/o0WsenQ9HeJuKK246nw?= =?us-ascii?Q?Jp2gwglhUUWKYusctaml1cEkvLTHeX7dTQ23yaJwgrh/c6i4is1EBxaEM7DD?= =?us-ascii?Q?XTe34LPCTGjoKpIX4e3rRNVu/pVunFaf2a0QB75WsNN/GdFDoKr/sWMQkusZ?= =?us-ascii?Q?cO9NXV+4fZqIL8DuF/gANyFrWZJL+5TWCZ3O3TGwLqgvCvcTFpNW+0LLWWwr?= =?us-ascii?Q?afvy+WyrSYDr2kPUAunaNzHjn4pLrluKugI2IL7gmT5vyfxzQgxRS3lEazKO?= =?us-ascii?Q?wYUdQtzki0BCVsrjeWvttnWRbiNIfKCV4t6kOe2ACDB5xeCR1oJUsyrzBTec?= =?us-ascii?Q?7lmDTUPpiYLe/mG9IjJmyIi0rsRNnNmKDsP0nR5O4mJOp7c3ytT4JjaEBCOs?= =?us-ascii?Q?yRk5xjVLVAkJm8PbYQvG1lT3+xC1hyzT6Q9c7yB1yWph9V1ajj02kybPQ7Qm?= =?us-ascii?Q?DgFOZro0CZcbRv3NdzERziBjWqVW6BRDsXSO7J2oEu0v9YK3DI02X2EaJxlR?= =?us-ascii?Q?jRxqUIqACBBOk9+daoihqpj7j2O2KTP39NAsPHJJbVVxdmnfVToP3dfJwT9a?= =?us-ascii?Q?p3KDAlkDr7GVw2DMlQmWiNjjHcULR4E7CkXvIr4pEVlGVccxbSMchnsNgCUE?= =?us-ascii?Q?aop0HkDW+oGEjjoVfPjx99nSDCPBhMCP3BdtiPx54UPNHmub+iPpPuJCBfAl?= =?us-ascii?Q?CAuZf7rsG7ryCgAllup6CcipPV5SFmgFExui4aBe/4PvIBrJXADmc6VCpqgQ?= =?us-ascii?Q?0Zd3vlJzAHf6zdHqui0nHjIWhgkGlL4sOaicAdm1SphEZLNpExdg1pV35kO8?= =?us-ascii?Q?xh+yL7Xrzdn/GyV3WVV6L6kynsiYATMiWFGepDqB8UQwUre+fo3y2mEt5o8D?= =?us-ascii?Q?UaPLj6xAuNrBuOktHO+xw1wEaP4OynXc2SbMvKOnJ1xPAg2ylDTH22dy7bvY?= =?us-ascii?Q?dgmlpz8sSylfqkCTK+QxKuFNWhTVbwiArrAm2QDFh9KoVa31RRuLBgwC2m/t?= =?us-ascii?Q?Wd2391zqK/pACwk/YQgQqIt2ZFgLAiCE8KpO91YOjw=3D=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ0PR10MB5613.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?McIkrsVwfYXS0YuE2JVw4YG8E6uGPu/Ckb7w0vrYQDWfMKP2cgPr3g2lum2k?= =?us-ascii?Q?ihqZSI9NuUrnkutSplm/HTZN1GTXB59XLGUYBXnkdMMzR9ib+PLcZ0QpEg8D?= =?us-ascii?Q?4bVVZMtDPHWFc3vv2I5Imwke4CiM6R800PETifRRc82ss88xrcry7EE9qrGt?= =?us-ascii?Q?fekaJ6K0va2KgBh3iVY5z7D82e/kYoWuobqCcC3fGLIgSbj2L9c/vOGGW4lU?= =?us-ascii?Q?9NOOq4TrWvvJL25pqRlUS+d/L/mHG8IOBOYptPY1RXvvV4C5Bo3aB7fPWGl6?= =?us-ascii?Q?c6gAy1p3FiMPRKnncSIGR6FLrU6u5HLpFonooJNVpXT4LdapjYtFnWE5lgio?= =?us-ascii?Q?ocKJhpZWxjA+eD381bHcYNrfjmPtKvHwCV/u9+CJHIdtIlBM2H7ONJ8BK2SM?= =?us-ascii?Q?4Wp5NAg4DbchKcYxVcREeYh45524pxBmkxnG3xuwRxs/KzblpRsMjZ8admb2?= =?us-ascii?Q?LOAi4DXgwXaG/5o9iy6EBLHlRMMODd10Hq7VXsZqo40otqkE50DldPluKQh+?= =?us-ascii?Q?g23D7FeF/NxgThDujaY/oqBuujt3Cx0HkJtSpb1BJRDAKhLiV4CW+/Uryg15?= =?us-ascii?Q?gcpmNTW9lhyTqAGJtadN3Cq2HHOh13sYadZ/1vG7ouk4SR5QLbq9NTQRtkGf?= =?us-ascii?Q?s6UxzadFFGn349KK/dTTPg29DD5b4fQ5tASag910j3TAWMSUm/fKCNIw2d+u?= =?us-ascii?Q?U7orH6WJNcE4MyvRDIephKhf2Z5s5rsvvb/DzckN+ZsAqMqoLTXIUqLrBEAV?= =?us-ascii?Q?z6R7lzzPH/z0S4hT0uG4wlkLaH9/BsSItCcWT/K9+huqfS18Qf4vh2u3cCkb?= =?us-ascii?Q?ERiYPzG5rFQSdM/S++Xw/XlYx99FbEmP634PbyRWxfLrsCZSGdykG4a1vQ2w?= =?us-ascii?Q?ho1DYJpx73x2r/uTQtIKqMYrqWvq61duNFjTRdo5xP/JzMmhVeIH3DOQ8BbR?= =?us-ascii?Q?msEVZDZiCXSKwphFphaCXSJTt2P8rIyExQP4BnflAnaDOiRGOemN41pV+vVW?= =?us-ascii?Q?7ldxNE73twihHtUFdDzFMXf4oO9M8hsn9AgDyM4geoh3fZt1pTOj9/KBTwOS?= =?us-ascii?Q?Ju75uS12i5MlUQFRV3XI1cmKdxWKN4JNoGkHMqamYwUjc4jcM6wcPRGEU6AG?= =?us-ascii?Q?rWwCtAhVN5QVovMaFqtR8kv+HQiUfRUKFIzJaYN4qqHcORD4DR85UarOFvoG?= =?us-ascii?Q?xtmWdOzXmqVPxiCZKIuAKUhNYe/xUWinfAqYnYh1Z6bHi+5ICs/jxqifgZIS?= =?us-ascii?Q?L+F0o2Hu6P4IjHf4dtHhtXjvDmQu1w9Hk2ZV8Fv+Mu+YlO/BKv6iio8P5RF2?= =?us-ascii?Q?FvtDxVRBJ1LcSEGBID9O38mNngOQt7H75y8DDU6GbP7w/BzuYZABWbAGX7tQ?= =?us-ascii?Q?+aBP8zA/ObsBx1kU2NC2kQ3pebmuJStLW78il70Uxex0Ry9EZ4cxChZ/KCTe?= =?us-ascii?Q?soGFqrKuVXVRXk5ld7K7LVu05leLbjXowh0KvN8T2FNIeECDQNrqhLg7QJyL?= =?us-ascii?Q?zQyvpSad01HHVo8/KQBMjaLlD+v2OJgDokV4h4JBxo+o30uHyz+7b08ptlWp?= =?us-ascii?Q?kYFZmRy4O/FXxTY2fntpq8NMc7YPY2mELzuB913hfyM0d+qoeAUY5euOsi+a?= =?us-ascii?Q?dA=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 6FZJNFQK5dNLv89sApq+NzzAUOOnFvzchrD5Echj4Q2k4QVcZOaiN+9b35xyy1xSOY8d20g5h5xay1Nj+0jHMj09KpN4o7LFW0g7e5iYzCCMXigI+OSSaPSFsVfqLEKA4TcEcj6IyHPprGvJD+KpSCUhDMXtV1VNqOepoD//WhzeL1bke1YTAkAfnrbVcJb9gJBYBAtvWKohUcPxvq5A3FhLbzXrSGxJjNSG54qm19gTX1B182+AaaJSrQFXBU4yK5pVgKJxCp1p8dqqrH0YTdEiOUnzxGyU0RFHtT7FHxGhgwDvXKC+s9seTH5nz9CB1N2/rIi3HFu74RdttNAqGzoFoQJ1NDZjdGkyr7zBGuJkOuMZ/9dAeQpcoKAZ9lz8zJTR6MWf3XgpyIicKg8rQiJJgzgQyJY/CVeWiMIpNIqEhg9f0qAODrwrJ5pKOcZxHk3QGESmFDI2Y6kB1Td/346sqwFbi0T9CXHK1DGPQEEIadRt75IFfW9Sn5sBgoC6t67oeqETnLOMyu+mrz3hfqtdfXgDDggj+PmLRB7eBerWVljm0hJJJoIp72a7Piz9WE+H6QMrdJlKoHV+jw1fiq7ASSYh20w1afAZNCZJqMQ= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: bdcc838b-1787-4b08-3b2f-08dce18282c5 X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5613.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2024 19:03:03.8393 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: N74CwGUuWCv+9WdneezkX5K9DopiXbsP6wNVMIntM1HpugFN6rLi6fucroe5nEmSQbH2+xFIATfXWVyxPH1PkdWz1ml40i/fobj13JNNSvg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR10MB5703 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-09-30_18,2024-09-30_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 phishscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2408220000 definitions=main-2409300138 X-Proofpoint-ORIG-GUID: PQeMZCtHwMHN0A_MXxbpF6oDHuzQyX1F X-Proofpoint-GUID: PQeMZCtHwMHN0A_MXxbpF6oDHuzQyX1F X-Rspamd-Queue-Id: 286C480003 X-Stat-Signature: p3c46f5sznbzy6sj9huzbihra6k7is4f X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1727723007-321748 X-HE-Meta: U2FsdGVkX18//dLGXfXVQ/Z+YSWbmv/4nj2XMkj+Pey0YvQf4cTCnTuJAhAsvAWiGJ3YLBd/k+7oaHyvys9PZFiqquUQujvwun8DI03HrR3OSVfsBnIJmbOti/3cEf67kvXj6pX52bcRmSryOH3+cbyVFI/NwmtTAdDGE1rPUpP6aMM8yqXULZo9WDH8fzBywMT7JgF1MxHJWve7jm0ycw99SiTgxmQEb4IHiNgxRm1soqWnB0DfLCvzajNl28HF6dyD55CYgydABy7yX/8l7Lp82+laZCAiquxZ4kVYLr8/djVycU7EZl9INa4nFt99WeC3nnnYWK4SeVQrWlDaZVDqEPse7DmQclUq5LWewWil4LQAloUur+u1r1dYCF68onkNgJkcrAdOQAwzqwjwWVzUdiOZ+6zgT6qikJez8s9xOEt+Vuz+1CqD1QZ3YPQXkvDKqSMbSLyEPt33w6I/ULlBjkmZTjsdowQ/THC6YSaq3MbvvACrYk3FbX6S/T/tU7su08t6RZ4ACFabC89opALlWUAo/d2nMEJofe/EIce4/4CwgwiE+2tm3QJkkVMj75Z9O1eZgzoVLd0Ma2xYfRDzuPcPmB5jyS6y5c0oclO7xkV/0FgEYaMhdz+/99VL4B5yAMRjtrYGZUrDkB2v2mhyKveob7LOo/XGMigWew0APuIXNj5JIrM/HH5I6oNaXUDytoedxRW+/r34BMWRm21XvrR0atCyc3xKiFsMPDTvYvzE3CmaqsYXgMYFz6HkLKtx92cTG/N5tgS7ZR80lrMs1dmlyee4qadaJTWKjQO8tfuD0crG+6jT89WKwRIq2IzTI1kDrxU7QDEuh7qRNGS6GL7xx/RTacGFPrOBb6IK6brnSGUPNYQiWOa4L8Eq/O+31ROnhgPBGTW2bN3PrFagb+GIeGVlJ4+I4fMnRB2K6zt6AkYqmQINZaEi4dzD9svHKAKCMtTebFCYl0d ePn2myUK PvJm7UsRibjJ6Io9Pf3WqBcQiUGs/CzuHj5xeEtoOG58bKuj+A0EQooSVVug1nYm15+8R2MalIme9FZ7Q+8RmSDOhnqXwt09qeBY78bEH3+Wcn6dctuwnSdZmg77VoI1XNkQXSOrm2iyq03m3ckBZ7KcaR/Oy2qrX1Hh6uH/Jg3GW7fxekfnAV0u/G/zstPvyx4XgDCKSPv312aBeEF5GINGpzGJoK63Nlv0sZ2UeDkL+rsd2onwq2sB+RgKgSzk98W3HwmD0dcBfw1egZoDZ6gyyrdnvRr49TFGHv2iHNTuUwFkrei0c/wq8sIFyubIdpjtmqEg7lAByW1Ys1Ytpgq10JHOZXCSQ01BAxTTXthDL3rw+dpvxIgCSN/T+0iPxbL0v/ONNdcHfaOR7wgjl79JBkiw4EWqi0U1Vw8Zd2bAd6dY0z3ZgEag93bpWJpIIzTC/b6xkVzT09f+cnp+V8Nrj4BD+WmGpxIeOmUkzZqxbm61nPgjLeSTYjd5tw1QNd3GmKKMwSTSFVxj6Z/17si5DuFoNJeD6TnnBgRDfCvZxE0kR073jsdUA8tQN/4stCz9VOrHb5ChPeGBy9OuCq0czfrMMdmAFtQrZ+lgxlh9Q57U= 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: I'm sorry to be difficult, but for me this is a no :(. I explain below. On Sun, Sep 29, 2024 at 05:32:12PM GMT, qiwu.chen wrote: > Commit acd4b2ecf3bb2 ("fs/procfs: extract logic for getting VMA name > constituents") introduces a generic helper to get VMA name constituents. > Currently, it's statically defined and referenced in fs/proc/task_mmu.c, > which is not opened to users who want to query VMA name more efficiently. I don't know what you mean by 'efficiently'? What is inefficient? This seems more like a convenience function for debugging? > > This patch moves get_vma_name() from procfs to mm/mmap.c, and export it > for modules usage. > > There should be no functional changes. I'd call exporting an arbitrary VMA operation a functional change :) but guess it's up for debate. I'm not in favour of this patch as: The VMA needs to be locked correctly for this to work and we plan to adjust how that locking works over time, in fact relatively soon. Exporting this as a module-available function means we are more constrained in how we can proceed with such changes, even if officially we do not guarantee internal kernel API/ABI stability. Also, an 'exportable' version of this function would be one that asserted the locking for you and did various more checks to make sure the input/output parameters weren't trash, but again I don't think the maintenance burden of making that available is really worth it. Ideally I'd love VMAs to be an entirely internal implementation detail. Sadly things like fault handlers for file systems prevent that. But it very much minds me against exporting things any more than that. So yeah, sorry to be difficult on something seemingly rather trivial, but it's a no. > > Signed-off-by: qiwu.chen An aside, but I don't feel hugely comfortable with an email being sent from one account and signed off by another... I'm not sure on our policy on that though. > --- > fs/proc/task_mmu.c | 61 -------------------------------------- > include/linux/mm.h | 2 ++ > mm/mmap.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 76 insertions(+), 61 deletions(-) > > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 72f14fd59c2d..7d414c39367a 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -240,67 +240,6 @@ static int do_maps_open(struct inode *inode, struct file *file, > sizeof(struct proc_maps_private)); > } > > -static void get_vma_name(struct vm_area_struct *vma, > - const struct path **path, > - const char **name, > - const char **name_fmt) > -{ > - struct anon_vma_name *anon_name = vma->vm_mm ? anon_vma_name(vma) : NULL; > - > - *name = NULL; > - *path = NULL; > - *name_fmt = NULL; > - > - /* > - * Print the dentry name for named mappings, and a > - * special [heap] marker for the heap: > - */ > - if (vma->vm_file) { > - /* > - * If user named this anon shared memory via > - * prctl(PR_SET_VMA ..., use the provided name. > - */ > - if (anon_name) { > - *name_fmt = "[anon_shmem:%s]"; > - *name = anon_name->name; > - } else { > - *path = file_user_path(vma->vm_file); > - } > - return; > - } > - > - if (vma->vm_ops && vma->vm_ops->name) { > - *name = vma->vm_ops->name(vma); > - if (*name) > - return; > - } > - > - *name = arch_vma_name(vma); > - if (*name) > - return; > - > - if (!vma->vm_mm) { > - *name = "[vdso]"; > - return; > - } > - > - if (vma_is_initial_heap(vma)) { > - *name = "[heap]"; > - return; > - } > - > - if (vma_is_initial_stack(vma)) { > - *name = "[stack]"; > - return; > - } > - > - if (anon_name) { > - *name_fmt = "[anon:%s]"; > - *name = anon_name->name; > - return; > - } > -} > - > static void show_vma_header_prefix(struct seq_file *m, > unsigned long start, unsigned long end, > vm_flags_t flags, unsigned long long pgoff, > diff --git a/include/linux/mm.h b/include/linux/mm.h > index ecf63d2b0582..31abb857e11e 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -3418,6 +3418,8 @@ int expand_downwards(struct vm_area_struct *vma, unsigned long address); > extern struct vm_area_struct * find_vma(struct mm_struct * mm, unsigned long addr); > extern struct vm_area_struct * find_vma_prev(struct mm_struct * mm, unsigned long addr, > struct vm_area_struct **pprev); > +extern void get_vma_name(struct vm_area_struct *vma, const struct path **path, > + const char **name, const char **name_fmt); A nit (especially as I'm not in favour of this change) and you have no reason why you'd be aware of this so it's fine but - generally when we add functions here we don't include the extern keyword as it's unnecessary. > > /* > * Look up the first VMA which intersects the interval [start_addr, end_addr) > diff --git a/mm/mmap.c b/mm/mmap.c > index ee8f91eaadb9..d6ca383fc302 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -995,6 +995,80 @@ find_vma_prev(struct mm_struct *mm, unsigned long addr, > return vma; > } > > +/** > + * get_vma_name() - get VMA name with relevant pieces of data. > + * @vma: The vma to check > + * @path: The file path given to the vma > + * @name: The vma name > + * @name_fmt: The formatted vma name > + * > + * Extract generic logic to fetch relevant pieces of data to describe > + * VMA name. This could be just some string (either special constant or > + * user-provided), or a string with some formatted wrapping text (e.g., > + * "[anon_shmem:]"), or, commonly, file path. > + */ > +void get_vma_name(struct vm_area_struct *vma, > + const struct path **path, > + const char **name, > + const char **name_fmt) > +{ > + struct anon_vma_name *anon_name = vma->vm_mm ? anon_vma_name(vma) : NULL; > + > + *name = NULL; > + *path = NULL; > + *name_fmt = NULL; > + > + /* > + * Print the dentry name for named mappings, and a > + * special [heap] marker for the heap: > + */ > + if (vma->vm_file) { > + /* > + * If user named this anon shared memory via > + * prctl(PR_SET_VMA ..., use the provided name. > + */ > + if (anon_name) { > + *name_fmt = "[anon_shmem:%s]"; > + *name = anon_name->name; > + } else { > + *path = file_user_path(vma->vm_file); > + } > + return; > + } > + > + if (vma->vm_ops && vma->vm_ops->name) { > + *name = vma->vm_ops->name(vma); > + if (*name) > + return; > + } > + > + *name = arch_vma_name(vma); > + if (*name) > + return; > + > + if (!vma->vm_mm) { > + *name = "[vdso]"; > + return; > + } > + > + if (vma_is_initial_heap(vma)) { > + *name = "[heap]"; > + return; > + } > + > + if (vma_is_initial_stack(vma)) { > + *name = "[stack]"; > + return; > + } > + > + if (anon_name) { > + *name_fmt = "[anon:%s]"; > + *name = anon_name->name; > + return; > + } > +} > +EXPORT_SYMBOL(get_vma_name); It's a convenience thing, so I'd have preferred an EXPORT_SYMBOL_GPL() anyway. I have no desire to provide this kind of thing to binary blobs. > + > /* > * Verify that the stack growth is acceptable and > * update accounting. This is shared with both the > -- > 2.25.1 > >