Message ID | 20240531081230.310128-2-ying.huang@intel.com (mailing list archive) |
---|---|
State | New |
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 6F42AC27C4F for <linux-mm@archiver.kernel.org>; Fri, 31 May 2024 08:13:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D24436B0089; Fri, 31 May 2024 04:13:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CD2716B008C; Fri, 31 May 2024 04:13:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B254F6B0092; Fri, 31 May 2024 04:13:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8D6D36B0089 for <linux-mm@kvack.org>; Fri, 31 May 2024 04:13:01 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3075E1A1241 for <linux-mm@kvack.org>; Fri, 31 May 2024 08:13:01 +0000 (UTC) X-FDA: 82177975362.29.39C4253 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) by imf18.hostedemail.com (Postfix) with ESMTP id 0C1FB1C001D for <linux-mm@kvack.org>; Fri, 31 May 2024 08:12:58 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=YqzOHD4S; spf=pass (imf18.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.10 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717143179; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ccYnb6zhiB/aH/usWIdTsL879a4h4ytGkNRSAUGO+zk=; b=Tjhb+RQlTpT8M74lA/uZKNwofFqQVxQ/yopqOXAibXTWkc7ZFI0AMQvRMuqm+eF2yMiy0S DotTJuSFaJWyRdOIykPVS4jQjufFW+VR+61AAPX9sH1wjwA8c+fNyZadDEW5MtHWU1iihx 0xs0dG3ED7Vk7s0DiRcRs7Ew2cNVg8c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717143179; a=rsa-sha256; cv=none; b=H++zJFyFYY+fq4Rlosq1N8gNLWdi3VKF+O0BNJml5LzULCHiL1qKpMeq4Fa6Y5WWXNngo8 niiQ+ZdobRzf7GOLSXigBj/w/6lCLt3Gdf4eeTOw0Uf0c6ckF8uBySBPDzLJFdkgk1mNPg ldQAGDFdteAvixehyHn8j602xnO9l3o= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=YqzOHD4S; spf=pass (imf18.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.10 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1717143179; x=1748679179; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ikiPA1J5OkAmYTlYwym2P+F42MJMV8ZnlTu7TRlEtOg=; b=YqzOHD4S8jOZtNZE5eZuwDL1BdYwFYnekC0/vCh8Vr/kppIWDELLmIWO 2LZxKLjJFbueil/r0XZULahdomkqk0PpOGRHn6BcgnZDJZKr2yKmCXZxu 9vR27ZCKqkQrWEXwpeeg7zE9MbBvC58weXnC4eIHTmenqBn1PFl8AgMVs Ojt3Ubwg2uDq3sR/Qa5E/i+5OBTBYfk8RoUA5ppnp2cvwdaVDIHPSHXpZ W2bdt6kby4FVUCP1VeK/ht32KhrUtOmqCDrgToFhzugUpdglXpqdYNnEo AXFSBptwoDAaz8fjsV46XeP2MwN2OaBgsOWA2Q6C2PwPCNpUUcJenTc8L A==; X-CSE-ConnectionGUID: XNcGHCamR5mZ2UUN4YEvqg== X-CSE-MsgGUID: GMhM57rvQlKErJNCzWGvwA== X-IronPort-AV: E=McAfee;i="6600,9927,11088"; a="25079747" X-IronPort-AV: E=Sophos;i="6.08,203,1712646000"; d="scan'208";a="25079747" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 May 2024 01:12:58 -0700 X-CSE-ConnectionGUID: paWjvUcmRbmdg62OQ/tn+g== X-CSE-MsgGUID: RxkDEidERZauFldGWycaVw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,203,1712646000"; d="scan'208";a="59270933" Received: from unknown (HELO yhuang6-mobl2.ccr.corp.intel.com) ([10.255.30.35]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 May 2024 01:12:54 -0700 From: Huang Ying <ying.huang@intel.com> To: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Huang Ying <ying.huang@intel.com>, Hugh Dickins <hughd@google.com>, Alistair Popple <apopple@nvidia.com>, Anshuman Khandual <anshuman.khandual@arm.com>, David Hildenbrand <david@redhat.com>, Mel Gorman <mgorman@techsingularity.net>, Miaohe Lin <linmiaohe@huawei.com>, Minchan Kim <minchan@kernel.org>, Ryan Roberts <ryan.roberts@arm.com>, Yang Shi <shy828301@gmail.com>, Yu Zhao <yuzhao@google.com>, Kairui Song <kasong@tencent.com>, Barry Song <v-songbaohua@oppo.com>, Chris Li <chrisl@kernel.org>, Yosry Ahmed <yosryahmed@google.com> Subject: [PATCH 1/3] mm,swap: fix a theoretical underflow in readahead window calculation Date: Fri, 31 May 2024 16:12:28 +0800 Message-Id: <20240531081230.310128-2-ying.huang@intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240531081230.310128-1-ying.huang@intel.com> References: <20240531081230.310128-1-ying.huang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: cqhjusg4cjsoa9tmfmnmmbxdckb4s85m X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0C1FB1C001D X-HE-Tag: 1717143178-455785 X-HE-Meta: U2FsdGVkX1/cxCqsYPmeXvAxIKUzmPjOr7JaWCew6VXAjq42J22Cc9iXDpMtccB/6hlb+WHy1mwb5Uj/n3vkiJkI7cQ3s71j7cyek6PTUxfyyTleRPpEH1Mrnz0PbMiap3+vA9vwbPQ2QV8SHOtcLg/qs1JnBhYEYM/p6Zx3KI0zY/9zxUGuN69FRN4UKKMxgDaleNcFS0eAhKj00ZxIlfa0x+B/e+VVEJO1OSjXFq3D5dmuJyPdKu2LTkAplDqjq7BQm8AhA5ieZm7psDCdVuUkkJYnj5jvXIUsAeblWtsHM5nek4p536aBJZa2HubiriehLwBm+h+3hZj5aLk++Uik3uF/LwI2Ed6d+u++jGdLYnjkE1cmWzabQ6/ZZuZnWaFDP6MIB1PYgE37M2UjHvNfLipxexqRksNVHgKgXwq8/S696500zKYDYJTT67/kK/Rpsseyeo9JjeW932+XPuzhBkqDTYbs7j7vLr/SWhHXs4uje3m32G8KipfXVc70CFM4BjVzAaP9R0aQuUYVZC2BQGTceihofUdkZAayKj0y51VdarwE70OLXLRQOPfqF5JmmcvVLHO87TVzj46kP3wtmjVXxY4N9hWC5Udf7mCHaxVsIrl0Czx4Mf1YhW/9+Cs5cMlg9BMOW9WNlgtFG3KmRLCVO/G6IyLmmgxJostpFGwALX1oSn0dlZ7c3qLMmhenCYHgrBq2YOEN2v/uuD3099BPTTZPemjXc2oiYyhybHymll1GjJzmHyYQ9SMtC4LTU3J5COCicXnXJzWzF/y8jgKFiM4QyvlgM8D34PV4mU7Zf0V8Ca6PmvLHDJtVWQbOv/ktT6/SmXPUnVm0acOwhwosfoiwbIrU/C04Mz7wL/6eZ7BBes7v9TPv2jdBiL6stzHqdYLiPVvbCl0Tp/jyxgUplmfjfIk6LEyOZFixrs/tQAcbEjoDPGTKUY9SF/XPjq0vI/laRVXkrip SLcUKW71 zy/Jlk1sczQg30SV+7Gjv/BEtGfWe36dhtJhC/G56JNbillHicf6qL/z2crOVM0HVdEvB32vXf8VB7bxnyKU47ZPq+ybANHfAsGmpFCWg8bzjh0Mq9cjCZJk6n7K4E2LFksm3x1mxObZVTjEHXDe9y2pYzDrENw96uoqVJMTNyN69rakAyQoNCa/xV/7+8BYazpsUOv8EdqOYZ5gWdaKgdn2E0oxs8eTQC3D3MZS/tT5EMA7/uUiLMItibegVC+ze1HLqWb11/MKdnW+5oHgWCfXE9rNK16SXOdYVWaLb9K+rIi5HqFg9iOouhmS4jTECSXh27TfGqiOAHuB18LScr7DBnCzwFdWBKB/RKt17YClxADZxosn0xAcMCk7My1CxRhoraEFraQhuaUpxX9QAArRABGX4wLqC8/NhA4Xj7emFVR7VO7suB7iwFsVSTVJxN3xYTNu+VeZPNhUK0Ma13SF3qdyMseSY+k8hrEJehzJg5PyJ7zsxO9ed/xGsqFk2WHpoYFYu0N78OAX3V70t2viXnZS9eVKVl/iZPzzSUklalK/uDt3fR/edWNTGX9r+RCeY 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
mm,swap: cleanup VMA based swap readahead window calculation
|
expand
|
diff --git a/mm/swap_state.c b/mm/swap_state.c index 642c30d8376c..848c167df530 100644 --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -787,6 +787,8 @@ static void swap_ra_info(struct vm_fault *vmf, lpfn = fpfn - left; rpfn = fpfn + win - left; } + if ((long)lpfn < 0) + lpfn = 0; start = max3(lpfn, PFN_DOWN(vma->vm_start), PFN_DOWN(faddr & PMD_MASK)); end = min3(rpfn, PFN_DOWN(vma->vm_end),
In swap readahead window calculation, if the fault PFN is smaller than the readahead window size, underflow may occurs. This is only possible in theory, because the start of the virtual address space will not be used for anonymous pages in practice. Even if underflow occurs, there will be no functional bugs. In the worst cases, some swap entries may be swapped in incorrectly and some pages may be allocate on the wrong nodes. Anyway, we still needs to fix the issue via some underflow checking. Fixes: ec560175c0b6 ("mm, swap: VMA based swap readahead") Signed-off-by: "Huang, Ying" <ying.huang@intel.com> Cc: Hugh Dickins <hughd@google.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: David Hildenbrand <david@redhat.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Miaohe Lin <linmiaohe@huawei.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Yang Shi <shy828301@gmail.com> Cc: Yu Zhao <yuzhao@google.com> Cc: Kairui Song <kasong@tencent.com> Cc: Barry Song <v-songbaohua@oppo.com> Cc: Chris Li <chrisl@kernel.org> Cc: Yosry Ahmed <yosryahmed@google.com> --- mm/swap_state.c | 2 ++ 1 file changed, 2 insertions(+)