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 C0B5BD637CD for ; Wed, 13 Nov 2024 22:13:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34D9F6B008C; Wed, 13 Nov 2024 17:13:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FD066B0093; Wed, 13 Nov 2024 17:13:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 150226B0095; Wed, 13 Nov 2024 17:13:42 -0500 (EST) 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 E4F446B008C for ; Wed, 13 Nov 2024 17:13:41 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9DCC0C016D for ; Wed, 13 Nov 2024 22:13:41 +0000 (UTC) X-FDA: 82782473760.18.D422CF4 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) by imf25.hostedemail.com (Postfix) with ESMTP id 3129EA0005 for ; Wed, 13 Nov 2024 22:13:05 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Cls5PXQU; spf=pass (imf25.hostedemail.com: domain of kanchana.p.sridhar@intel.com designates 198.175.65.21 as permitted sender) smtp.mailfrom=kanchana.p.sridhar@intel.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731535843; 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:dkim-signature; bh=Vvp6TkyVPEXdjvVh7YSX35ckrvvoss5MPvtt3f+R504=; b=vTTa1PWEnw3kH+eTzPnAT8tOft0MWIfT9bqBXG0c1TBqAO6bHQDTNG1I4p8mSIPid5Fde0 ux1Jo1ioWLu/JMstUIhVIMMt+Pay7fhW7ciyZAi5sq8xxsF3X0wasshKr28cC3WIQMZuD2 O3hR+i3xqymHGGgsM/UPDGYJTHwN7GU= ARC-Authentication-Results: i=2; imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Cls5PXQU; spf=pass (imf25.hostedemail.com: domain of kanchana.p.sridhar@intel.com designates 198.175.65.21 as permitted sender) smtp.mailfrom=kanchana.p.sridhar@intel.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1731535843; a=rsa-sha256; cv=pass; b=r02X83NGKmF384mlqFi06/blQuDy+4FjzVkZCTkRQNaTFXtJSWBQnUEwbfu/EV+COiwvUE 7IPf+VLDrAcFYL/GFyysOkmg0WEveM1v4aS0XurxE2B/8+R19oCoBDMqqHyyliaGbG4Y5u 6O8FRTb1SCAcsMKOf5RGU5Aq3Abv27Y= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1731536018; x=1763072018; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vJZmddrdZbzYoAs4HBfNQCS2kXLQr/nP77hsQtj7ZFA=; b=Cls5PXQUzCo48pYUsT+sgjYIQ8QsT458zRVkRIdPDGEkThWzbNVYecfT 4J3okUnIeW6K9Ss1+giQgAxAE0+HwyKD+xjiJcVylMeLw9g67AWR6WqzF 8davq04Iyuea0Jn8lhQTdQhwbPVPmKFFiPMDMU8G0rS0VCvTFtuhKjoa9 tO0LxRmdZO0vdmHQCSS3laTDKAUZhTcNFE1uqpmsUWKRrQlojeBqP8Ck1 BTK2YYVKmxXxn10NaJjLKGwsI94OKVp43EF8q7ScZI7EasN9MR25pk+C4 qExQ7cHObD0rwsIolmnfbJvP3R05GxhHL21kd++0H/EHA6t+dUN2+U6/H g==; X-CSE-ConnectionGUID: dqgQSxSqTnCuUDP5snk61Q== X-CSE-MsgGUID: 9uc6xJJ9RiuKNopWONMFfA== X-IronPort-AV: E=McAfee;i="6700,10204,11222"; a="31424678" X-IronPort-AV: E=Sophos;i="6.11,199,1725346800"; d="scan'208";a="31424678" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2024 14:13:37 -0800 X-CSE-ConnectionGUID: VKCNdSu9QhSE5BGORc6ysQ== X-CSE-MsgGUID: NK8QWItnR46lM0/co5Am7g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,152,1728975600"; d="scan'208";a="118944681" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmviesa001.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 13 Nov 2024 14:13:36 -0800 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 13 Nov 2024 14:13:35 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Wed, 13 Nov 2024 14:13:35 -0800 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.169) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 13 Nov 2024 14:13:35 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZMFNpmsp3MMvRaQF8KY4UXKKcqR05HuHPqYckvaobagoEbVN9OXVYIIXXKFIrq+s4putzI/9KmS9PHGLr4XGCYlrrFlGy+O23+/vz7IWX3u7yCeqcZLcvmSvrYz8qS0kWe6cP99xm8lreYgFcCLjRtb3FNf/65IRXfYjxwrFga2Ta9cG4bLe0YyMRgiiRBFlv/lJx96iR3Gxj71/mMlh/YkcWvf+Zj0M9OiWS13PxjxxmlB7e1aAg8BlZuLtCKFUVUsdtPakW8omJjtdYAhDX1kWLTUgrFLSTIT6ccaNosJfGARXeWqGeI4fjJCDE3hRXDOPp9MJGGnmcHGVK7/ZWA== 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=Vvp6TkyVPEXdjvVh7YSX35ckrvvoss5MPvtt3f+R504=; b=J8IydW9JuRKYFkVvncrRadx9HEzxOpyExGMiyzi7iBjumlkwkPRB7pboY3/9Q/zCw+UwDmJ8uDjNjquO8mIhyMRRN+6Pcw05qqGPk4GvF5K5s6RF9jacE1aoSm+pUqF5vuIhV8zHdfyxrfIKlsw9R7aAUEKUQdv1v0JC80HflIAajTUMH8b4+GkdRQeH4ASWaTn1VFPgrUd8OPILbQHrJpx9a/M2oJGTKEynkask9rVIdKq9LOTMJsGh/CeLdDVorTHQx4qifnUaKZNCBJ56/Lo7F88VRksqN6fJz+/SuEpuD234SWtgRxKThji/fWpVq5Mr4kC7/8V7qsmjQdzBEw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from SJ0PR11MB5678.namprd11.prod.outlook.com (2603:10b6:a03:3b8::22) by SA1PR11MB8279.namprd11.prod.outlook.com (2603:10b6:806:25c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8137.28; Wed, 13 Nov 2024 22:13:32 +0000 Received: from SJ0PR11MB5678.namprd11.prod.outlook.com ([fe80::812:6f53:13d:609c]) by SJ0PR11MB5678.namprd11.prod.outlook.com ([fe80::812:6f53:13d:609c%4]) with mapi id 15.20.8158.013; Wed, 13 Nov 2024 22:13:32 +0000 From: "Sridhar, Kanchana P" To: Johannes Weiner CC: Yosry Ahmed , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "nphamcs@gmail.com" , "chengming.zhou@linux.dev" , "usamaarif642@gmail.com" , "ryan.roberts@arm.com" , "Huang, Ying" , "21cnbao@gmail.com" <21cnbao@gmail.com>, "akpm@linux-foundation.org" , "Feghali, Wajdi K" , "Gopal, Vinodh" , "Sridhar, Kanchana P" Subject: RE: [PATCH v1] mm: zswap: Fix a potential memory leak in zswap_decompress(). Thread-Topic: [PATCH v1] mm: zswap: Fix a potential memory leak in zswap_decompress(). Thread-Index: AQHbNYxgo97ShYNp0k+eAlG8E2BdYbK0sGWAgAAC9UCAAAo2gIAAydcggAAz64CAAATjwA== Date: Wed, 13 Nov 2024 22:13:32 +0000 Message-ID: References: <20241113052413.157039-1-kanchana.p.sridhar@intel.com> <20241113213007.GB1564047@cmpxchg.org> In-Reply-To: <20241113213007.GB1564047@cmpxchg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ0PR11MB5678:EE_|SA1PR11MB8279:EE_ x-ms-office365-filtering-correlation-id: b69bed4c-4f14-4835-cf8b-08dd043068e4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|7416014|366016|1800799024|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?3TM31KWPKFpXIwLgNFYjckhjQLGVZu8Dr3CLwymPnD/aj6XaZC50t0BTYJxI?= =?us-ascii?Q?kd7lRlHw3wOgLTGVSxgo2TEtVEPX08Z3fCtt7EZzYiPba6XNZRiCd62Ir1US?= =?us-ascii?Q?d60UjMlXfoQWZnn3JIhQJAcF9rIs26Ykqq2TmD6+V2d0kjP086ePx9jlU2QB?= =?us-ascii?Q?86oTHeKM78oQStqB0Dy58ulH9FXJpJgxPW7CBYSviEs7D7mDW4TgU6rS4UEw?= =?us-ascii?Q?fJ6bNz4qBftmpSqhQL5W0ZkClFC+KUxkRUTWTlMrNJcd1UcVdTvGXVJeURkC?= =?us-ascii?Q?4nt3FMV7yYyMr177+7GafQh05hvy7D+LGjRgSvrsTJIj9qY6uf6/VXp0Tbq3?= =?us-ascii?Q?YASnt0WqntEZ6pldV+Mx6m2jsdjn9SnzuJ/Ei+SKbCwMAoSLzlaFI4BIpcMM?= =?us-ascii?Q?aPn6XxvbxYDFIapMyLvfIaZu15+nP5ZA0Li7ZUEStljT9+oKzHT1g6Cfgh1l?= =?us-ascii?Q?dDWPLnBa0p+QnhmrHfqED9GKbC/sc2xXYI6w8mFSAwUHN8bZACJiy8d5sDvn?= =?us-ascii?Q?HKe4x/+wOFBQKR9GhiqMx7AzQPxmOxJ3aVCP7jxxKgU8+nIOI1x5fdl6tBkE?= =?us-ascii?Q?BtNDrReNz9/qBU4YHf1wQ9ToIK4Ksx2POFV830D258rQ5A/ttW+inpYzhF8P?= =?us-ascii?Q?bcFQc0y+T9aZmNbz7xYOVcNu/CE2CUsrIri3WtFLVReCowEI0G6+2dRc3BUR?= =?us-ascii?Q?m0qfFvSjeYV3GWz+ytgFiKhZopKytmPhSG+4vypGEbgKJezZZCcaMbSW23nZ?= =?us-ascii?Q?t70QWO4mDRv57lRD6eWy1Y4D0yE3QjtC9HX3wOAgIkv9t//vf+kYYleTkp9F?= =?us-ascii?Q?CMMfAe43Tq0Hk7xuNAiWiervw4NT55a/cpVsqgCe/WckQ57PDVmBheEuI1P3?= =?us-ascii?Q?NVETp34Ym74dCep2XvHJz6EFcvGb0VuGxduld1QrykEkdrwdfND6+pKNZI7U?= =?us-ascii?Q?JknYO3CMPNWdfSo63lcJhhQZ+h7W73sLX8cggmjs3hk6cM8V0rY34lL84Aho?= =?us-ascii?Q?qqQve43SF/6QzqIaA7PgmOM2mwyuYC763v3gysIsORM5LGAZa/JxUumKTYyy?= =?us-ascii?Q?aXdWaxIPRjr9pxOC+ntkJ8J7dHAvZ21ba2EiexiPEGHdtcrHLwPHsUXb4a7S?= =?us-ascii?Q?6Q2L74x9QU6mmAAKIG2558r4hPQvOa1clnnGRnnR2Gd5icDKnN1/T9sgibTU?= =?us-ascii?Q?27LMM59yKi6aWtlCkqpS3MvYNd8PNuEvix+46y57YKT5jPX5lmuj4S+ZoTj+?= =?us-ascii?Q?cApzh35OstfcjVX3zNktWr8ALBUlq1vD2tsbPhuiDBRG+tacBUuGxv3mw0TX?= =?us-ascii?Q?d4WPxjMPY/R//VmbmeAf9H1cPXtMxyP6+V4yIsklsO8wzrzfT4T1RSZHbpK0?= =?us-ascii?Q?wAQrh3g=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ0PR11MB5678.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?7mfa03mwavLwFRP3YqdejYyf8nd/ftB3ALWbW3dbB8Wj83IqbSf6U9Vpx1Sl?= =?us-ascii?Q?2RmTGj5lCvOc0+nm4b2lBb6BpJmgHa3o+3FfbrTk9hnb38L32QaRtJko2/3U?= =?us-ascii?Q?5Ouky2nDufdSGDTWFZymT0RpnODVrYSrSCzqGOJPEzmSNfMn7ehURJU4pNNs?= =?us-ascii?Q?w4R7uJHKwbmSLwXEFHUKKtZY7SaHBc4rCjm/YMid16C1+yySRnltPU4ZfXPn?= =?us-ascii?Q?uenOwuVECAKqlX+Qz67MexfYn/C9c0ON4oL+C2QCdatDRX9ZB11ATz0tytsS?= =?us-ascii?Q?vScoAH91dc+f8abFVhp8pywBbqF9Yn5vzS2OdyvR4aipFtDycwM39oCXivlF?= =?us-ascii?Q?7ozlJXVt2i4YPnHnm5Lso9s8HVqTq1rkwjd5MYWNlKTobl9GGozdUXU5OUzd?= =?us-ascii?Q?R2Hg8fzVrkD5RR9U3r2L1zyqToaHGsJv3v8o932Q2tL6yApmRfH2+tax+h+j?= =?us-ascii?Q?LK7KZ88cGRJ4xqjWkJ3qlT2TG/Zjeof1epLyZAMaxY3LzzzoDhxjXRTGsmUs?= =?us-ascii?Q?CKOhapvJRASz/4pJ0rvLSBONKFrZ6qPuRW7kgUuwtpyBcpl0Zzz6dho8EtUT?= =?us-ascii?Q?DfiUDpID5qt2JFMasiEUYQbzlrCJzUk5pSKqDgLvxzQ6GWfVpwo8qBUeDKEB?= =?us-ascii?Q?nTo+9bEcfL3WAXtEkvg55q6drEoS847jYB/dMPZccJig7eHz9zGv2zELQWOX?= =?us-ascii?Q?6zAIAmT9ft42hfgnWMgZUqYmZUHat4Yfje1OikxwnwhbVxE7250qUGGj9Jd6?= =?us-ascii?Q?An4764hXO2Z3ZNEPsyPcNr+sO8zqp15nfNPcCcRRNcL+k1NDkymXVHa4HEnQ?= =?us-ascii?Q?U80NzyEMt3cLiUAoKY9cAwSTp5Ge5p69dh9EwRPWnbiSYFliDlhPqKB0RytE?= =?us-ascii?Q?ZFMm0UP+PxnV/5uFksjE1kx6hAZ174KxjdPalfy05Ahki9nshH94PAJnK1qD?= =?us-ascii?Q?1pzt1sngBZTiMNfKhiEhBj0OugU8UohUUgbhLxyAMgGOzpDtYkbMvN1Tj/+n?= =?us-ascii?Q?PcQp+8gNLhsFyqcAQRmzJhHbKFsUV4JNXPetKrkTYbAQCCXQU0K92H5Cu52I?= =?us-ascii?Q?uaZrJN2S9ILb1kx1YlykB7t4jreFgesnZjqkeJYXd37ABZ19XD1JWBXEIask?= =?us-ascii?Q?IyGY0HvMlfRdCbaOkyPZLp6yvjIrZBTITDTTLVp7nLOQTf5Z2xn/298LgnxU?= =?us-ascii?Q?xCaC2V5nPLfLAn8AuMuvZFIC7eGVH1hgLd9ugflrfromk+ItNBJX7bAEIKh/?= =?us-ascii?Q?8Ds3I1sbUR5uM03hoLxvrySWAJSui/e5uYnz0v90eKVBUgKzAjm9azNgxV41?= =?us-ascii?Q?3ZL1+nzvl+Cc1+gY6/bkjCpJGdYvSANKvyb3x/Gjxln+KNQpLTOIiFP+X06J?= =?us-ascii?Q?UYCXOVyh9NJYBGmAlhoJkgD9JTmy+e/qMp9WhXb+8TNj6jEnP0xeIqOiFKmz?= =?us-ascii?Q?UPRq/dlZdZzvopqnsAEyl5NSgJ+n57oLmNnKuZZFQR/qxmhLvhf4dkD6rWYb?= =?us-ascii?Q?KhuzyI99R2I3xoaVMifp+jbfRIIviDsXTKglkX2QflugefUEpgwlxw6mnfTM?= =?us-ascii?Q?WoTL47Q2rd1f1wr2/pYYdb5atoW2D60+wTpgMWTAEgeQGu+OSZsQ7tqHMnTt?= =?us-ascii?Q?JQ=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5678.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b69bed4c-4f14-4835-cf8b-08dd043068e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2024 22:13:32.0627 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jq6UqyhI//E5+iGgPzOlmIKbSWxu9mmV7zjDB7U+yNPk3CLu93NRY2amen2jQD2+7dRNQN2hwmXT5FDlhaSEyN8V+/jFZWy5J6RfUmxYHvc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB8279 X-OriginatorOrg: intel.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 3129EA0005 X-Stat-Signature: sna6dtxew6audaf9ytakuw78q41f18bk X-Rspam-User: X-HE-Tag: 1731535985-809129 X-HE-Meta: U2FsdGVkX18xHkz/2ad4PbmrhY/tRz85QG6rafoO8++hx9kBgfNm10eC0dYKyPS+KHh3PhoHsi5pH7jJfuULLvWdrm6291Yx6cwJwPs8i5zN1k+oWA28WQ0Mn4wuTwD/l0tgPrgIaEZ6a0O5y4DKIRufMFqKwolKWd81sM415LCXXa4CWk/v+ikhnKnzfl1eX7Uw7VKR35h4F8mRvFlBgm0oAWGKVrS/0HlQ9+t5mietKavWTMQhjxTPHYkaWFKzqnGsXvFYHEIP7MOKLnzXRgdOrlqzPvXhJ57jzcAjz1KyPnnTcJY7Fh7eCNgQH+njiDeAxjIjSgoWAJeyT6w90X5a0AFvEFYb843AsBmupEFGkADuScT13xa0NMs9dmwaseHCEYUvOlJYPuTU5rRVSXiZ8hWJbj4Q5MzJZ47uhuK/wL8H7xv9jbf5sTQo60R06PjyFrIADNkIKY2gHms4/6zAvrkqJ8754DMEkknKDNuDodB7VWjX9sk00bXRpsdvh/NTDtzp74MASRFzAf6Q1qdsLoaiwoto8dm5srGiVVIc5Li2MDx2W40OVDWL1IZMzf5oHDW9GDm+SVqb+eKQAsVTSK3qFLxaSgd32I+HAPQZMKQKGglDh/uJL57+I/cML6ohW7WvUaMBKLOqLspeg92c5C20qX+kDhs08yfmX1Ch1TeLB/v1Kxr5CYxxxTCqtQymLawvOr+Pzr91pk5G8w26vjLtde61YbQ3TZBvvgepi++Upq++xxbxkHg2udYdw9hGxda5pw/gY+fwSZdzXZMhj+jEIh8iPQB2k08jwz1Sptz9o8ipohLoo3uJUGkmTrdgcBHxtlq44KSc1Rhr5FfYkO1VK4kTl7Y3SuU024glqLOtL18x/ua5KNj/3ajkqeIwUWnb+MaboJU6F4MOibLgrchkTlHLPjBwMCXC0mfsCH1efpitgVQW9lp1jk8oKQatIo6wkgsvxXGXkO6 AG76F4WV FGBFFN6jnri1FTc+KCVxhu+OIFXKj5M/M8gR3yhXPUMKIwL6ShbioCEnwn9a+lN63e2k8IA5Vdp2SFmFgrCxPUHmZj7WmEjGEsIdQgUNlAA/IJCjmC/kzFfJaeHjamNMiCJpe6QosUBP3n72vmfmL1SNnY96P4YU7sd7kwxac0bWhTHzSraaloZy1MgwoWE7xEa/IkXFVOQiNl+saSudmehWzs8+9DSOn2brJ5qyWll7MT0QmPs9lgAd/dlPyn4T9dEQAYLqVvoSw2JgjesDtuhSeunSJIicf6cbSfSEN2XqLBDIi9cdzINy64u0rqR3zTYgGVZtp1lL0uftHgGbTLb9/ePDQ2Q753P+gEgNG4be0v3dLBU2apxIwO3DpFRfogvL2ZoZRqKfrm8A4MoRkc63FTJAnXSzrp9KLWFm2QUUFjbVrsCDuts7xtuTBeY/HyNqn7tItTwpr686MYDeOiM9H9FdWPbhNp6v6mGou2BdvTHKQd9pI+u4vm4H1lkYtSwESPrZP73JuD/Y672+wsjMSaeDKCjiaN4VeAU4b+CPkGeYr2GR2WmZ3tF0+x6rmxlLK7HvqaxPpfsD/Nur49UTxOs6EY+Dm0yk2q9evvhw5rs+qYIYEFfIQuKX9t4IA6G26JrKBsAnHuKmeCaru1hNfVFyCLMlHFkL377lJunMhCDmBNqWTaxzi+hHkMujlRW/poxhAtmIsVG2Cu7SaA+eaJc8cs0JaEuRnG5fYo46BCWbeggmnF4GlMZNPNqI+HiwW+NYpMfK5hiBEfBg/w2X+iL4NcusGhx7j8mtxd54JD3YSXElJLFbKgOPqqP0zDRNaUx48WYoYvh0mgDg3d+cVlM1HOcrcU2rnw3eQckwFe6A= 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: > -----Original Message----- > From: Johannes Weiner > Sent: Wednesday, November 13, 2024 1:30 PM > To: Sridhar, Kanchana P > Cc: Yosry Ahmed ; linux-kernel@vger.kernel.org; > linux-mm@kvack.org; nphamcs@gmail.com; chengming.zhou@linux.dev; > usamaarif642@gmail.com; ryan.roberts@arm.com; Huang, Ying > ; 21cnbao@gmail.com; akpm@linux-foundation.org; > Feghali, Wajdi K ; Gopal, Vinodh > > Subject: Re: [PATCH v1] mm: zswap: Fix a potential memory leak in > zswap_decompress(). >=20 > On Wed, Nov 13, 2024 at 07:12:18PM +0000, Sridhar, Kanchana P wrote: > > I am still thinking moving the mutex_unlock() could help, or at least h= ave > > no downside. The acomp_ctx is per-cpu and it's mutex_lock/unlock > > safeguards the interaction between the decompress operation, the > > sg_*() API calls inside zswap_decompress() and the shared zpool. > > > > If we release the per-cpu acomp_ctx's mutex lock before the > > zpool_unmap_handle(), is it possible that another cpu could acquire > > it's acomp_ctx's lock and map the same zpool handle (that the earlier > > cpu has yet to unmap or is concurrently unmapping) for a write? > > If this could happen, would it result in undefined state for both > > these zpool ops on different cpu's? >=20 > The code is fine as is. >=20 > Like you said, acomp_ctx->buffer (the pointer) doesn't change. It > points to whatever was kmalloced in zswap_cpu_comp_prepare(). The > handle points to backend memory. Neither of those addresses can change > under us. There is no confusing them, and they cannot coincide. >=20 > The mutex guards the *memory* behind the buffer, so that we don't have > multiple (de)compressors stepping on each others' toes. But it's fine > to drop the mutex once we're done working with the memory. We don't > need the mutex to check whether src holds the acomp buffer address. Thanks Johannes, for these insights. I was thinking of the following in zswap_decompress() as creating a non-preemptible context because of the call to raw_cpu_ptr() at the start; with this context extending until the mutex_unlock(): acomp_ctx =3D raw_cpu_ptr(entry->pool->acomp_ctx); mutex_lock(&acomp_ctx->mutex); [...] mutex_unlock(&acomp_ctx->mutex); if (src !=3D acomp_ctx->buffer) zpool_unmap_handle(zpool, entry->handle); Based on this understanding, I was a bit worried about the "acomp_ctx->buffer" in the conditional that gates the zpool_unmap_handle() not being the same acomp_ctx as the one at the beginning. I may have been confusing myself, since the acomp_ctx is not re-evaluated before the conditional, just reused from the start. My apologies to you and Yosry! >=20 > That being said, I do think there is a UAF bug in CPU hotplugging. >=20 > There is an acomp_ctx for each cpu, but note that this is best effort > parallelism, not a guarantee that we always have the context of the > local CPU. Look closely: we pick the "local" CPU with preemption > enabled, then contend for the mutex. This may well put us to sleep and > get us migrated, so we could be using the context of a CPU we are no > longer running on. This is fine because we hold the mutex - if that > other CPU tries to use the acomp_ctx, it'll wait for us. >=20 > However, if we get migrated and vacate the CPU whose context we have > locked, the CPU might get offlined and zswap_cpu_comp_dead() can free > the context underneath us. I think we need to refcount the acomp_ctx. I see. Wouldn't it then seem to make the code more fail-safe to not allow the migration to happen until after the check for (src !=3D acomp_ctx->buff= er), by moving the mutex_unlock() after this check? Or, use a boolean to determine if the unmap_handle needs to be done as Yosry suggested? Thanks, Kanchana