From patchwork Sun Apr 7 06:54:50 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Huang, Ying" X-Patchwork-Id: 13620014 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 B37C3CD11C2 for ; Sun, 7 Apr 2024 06:55:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0AD726B0088; Sun, 7 Apr 2024 02:55:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 035986B0089; Sun, 7 Apr 2024 02:55:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E186F6B008A; Sun, 7 Apr 2024 02:55:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BF9996B0088 for ; Sun, 7 Apr 2024 02:55:10 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 78DCD160864 for ; Sun, 7 Apr 2024 06:55:10 +0000 (UTC) X-FDA: 81981823980.09.29F1EC0 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf25.hostedemail.com (Postfix) with ESMTP id EC0DFA000A for ; Sun, 7 Apr 2024 06:55:06 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=nCgX9K3r; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf25.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.15 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712472907; 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:references:dkim-signature; bh=hGkWrkSwuB6XImaQOxuRnDWiN8Nv8s3YVG791x/y61E=; b=GWXwDXyEyXhqwhYjcRFvEjSCkhPS1953LE19D/keBcniL0xVMvwuT4IgGLLkozltmLW1Ms D2R5ZoUueSw6ygFZ0siNlOO4L9FvxtaNJ4O5HSAUak4fj1Y157olxjQQXFOjSFZjsTbhGN 7Rj5cCK/nl7YjGJAXQkpRD92IJRomjY= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=nCgX9K3r; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf25.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.15 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712472907; a=rsa-sha256; cv=none; b=uQiB2tYRKxZFk4aYIzaga4qkMOXCZX1Vi/JmYkeJFFjK3RCguepcpnsMjfKhcXS0llyFGh pRaVKpkWJI3UHLNtiDBHn6davVJ0D9MO1kgjmMN5b149IJcunVNvI3crVamiCtv46Oqjph aCOkkvl1YCMY31Ch8DI77yE8V66qfRA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712472908; x=1744008908; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=iCd4mqulyCBb7Qt4H3d7QCvUjxPxbKW3n2d2uZXJx4M=; b=nCgX9K3roxGb68irNoXFGn2WNSwdWTuAUG62/4JMfFs0IdDLeFSmwwc8 dKUkxGEO7zB+LycyiqN/NQ98W5CosHaE32cV94HiwKDSZX/xImAvRmhyh cRJT9xsBPZw8Wc7+1kCxxtE1KWBgl/FWUTR3ZQwNJ0LmrO8poho9WL5JQ 2nAjiIvEKuDanr6dgQ+5TcwazNYVXJKIn5mmOUTxVtcc+3/GPpQQe/Wwe F8hpgOhfKcGBj3FM6jD0sUvRAZ77aa6xJK3AFR85KYsTTHk26EqIl3vh/ rbgo9DdBRqnSPxSv/hM3nmBJlcW1MioKSX9lyL+VSjzBxsd28ZWrM/cB6 A==; X-CSE-ConnectionGUID: qhVjOeMTTzGQxTwUmhVHag== X-CSE-MsgGUID: yK6ttLukTha2yohRheqLwQ== X-IronPort-AV: E=McAfee;i="6600,9927,11036"; a="11553344" X-IronPort-AV: E=Sophos;i="6.07,184,1708416000"; d="scan'208";a="11553344" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2024 23:55:06 -0700 X-CSE-ConnectionGUID: p7xOMK39Rwu9L0HLtgKMNw== X-CSE-MsgGUID: vXEl9dyTRHuimbx6P1capg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,184,1708416000"; d="scan'208";a="24243470" Received: from yangdaiy-mobl.ccr.corp.intel.com (HELO yhuang6-mobl2.ccr.corp.intel.com) ([10.255.29.196]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2024 23:55:03 -0700 From: Huang Ying To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Huang Ying , Ryan Roberts , David Hildenbrand , Miaohe Lin , Hugh Dickins , Minchan Kim Subject: [PATCH] mm,swap: add document about RCU read lock and swapoff interaction Date: Sun, 7 Apr 2024 14:54:50 +0800 Message-Id: <20240407065450.498821-1-ying.huang@intel.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: EC0DFA000A X-Stat-Signature: m7tmd7i8gnd19b7z7od4sn3yon6n13x1 X-HE-Tag: 1712472906-554401 X-HE-Meta: U2FsdGVkX1/RnU3b4lSuno7NS3or1Hgm2ezHjFbYK+Wdl39gjr5SC0L/Ff9G+e8RKtiroD3P21rpDQTke2lffYvio0jvQcDrMXNH8lVvW7koTbtbO9iQLjycLYP+YOxpFNXVMSNaPx/Ul6A+YhLR5Kramv8a+x1pIQ/9536FoPaeysAsSsp7V2FgtoBZmMH79yEfwdB8ucDDr4ySzu+iX/z1rTJjLUJRgCVF1d/TecVY4ccXBFbMxuZnncC60rFDi1aQLN+o/yxiZWONAoaKX4IXzFbMqDCvFSnUtpBuEHLkoZN7qdxcI7xsIsTqgZMePIxRjPi868LdydjrYi+PXaledLbBhpciuakpSZM4vhI8YLitheRqPxtWMA80GaVSxyRpFtQFMrvbfKMvMJsq6ERRXhaQJ+q6AwKiouSztl9TYzQsWx8BjmfD9Oya0joTm+I0Kn18fcoVZwrpS/0ORr/MEX89+hBRZezrDtDeIdTVRLzFT4N6mQWp1PTiAhWX8Wk/2r2GEv4mpVoisA2fPWWs2RkEUYECNRWx759ZnKmtTwNshMaEqlr2bPhB3VZctP22Ol7ErvrZJ6vzqMOVNd8wIqe2FAX7NBVf6IbgZ31HAFizpsI/NirChPMzYx9I1KSyk+NmlA0iG5Go0ArL5NCNi7HRhEsGIb2TdrUbqaAod7nZqXFOCW7Wfmw1hmJ86m4sFU5o9DKHMXa3rk5dxXpf7y9ECbMhjuqgQY2E1cKnfxFmEhEdH35Uoi3o+dEn11PMNKrtLsNjKmVB9GY2nQlsFTqzIBB/SuVQre2eIq5VVVsBURMjfrXYqgPxTjRxZ2S64CTplQYWCbiU4fB1vBDIN2onX+R7j8HxufTw0+IiP2dAzX/cUsSG32psgNhJjCG3v6jGn36zAqApI0b19GbgKT+QMS8y+pJtFA+sMQL6qx/wlP1qc9KUWcGAbXquaFZNlCS8RwQPlx40DOr zYoQu+Xo S7SErdxET9BOvgYMH+IBb1H6XSlYLjNZfgDwnSAKaNIkD4aU0LUMZl8F8DzmfrfjgpQTUEZwS/CwAf3FIbB1o3+8jN+RTlEBCgU8f8BMKBqBvgonQsOiGUKN0gToA0ChjqMhDfYTuUzKrFm0NnJ6Pkgt9eiuMR29ikNtjiE/70x4J3KBrQo2EBJHpWnDa+pWiMwgs1Mwtctt3+bcFgiJ5pP77N2ZsgWt94aPY7dwyN3gJF9eUluxmBG6ohzX381YIl1KnkmY882o7MEsayDzrWCq32+RQGGAKHVsNOoo2wqOrD0ladKYjGeYPGSFxOUSHq7BDKx6sVn722+arIML70QixBg== 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: During reviewing a patch to fix the race condition between free_swap_and_cache() and swapoff() [1], it was found that the document about how to prevent racing with swapoff isn't clear enough. Especially RCU read lock can prevent swapoff from freeing data structures. So, the document is added as comments. [1] https://lore.kernel.org/linux-mm/c8fe62d0-78b8-527a-5bef-ee663ccdc37a@huawei.com/ Signed-off-by: "Huang, Ying" Cc: Ryan Roberts Cc: David Hildenbrand Cc: Miaohe Lin Cc: Hugh Dickins Cc: Minchan Kim Reviewed-by: Ryan Roberts Reviewed-by: David Hildenbrand Reviewed-by: Miaohe Lin --- mm/swapfile.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index 4919423cce76..6925462406fa 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -1226,16 +1226,15 @@ static unsigned char __swap_entry_free_locked(struct swap_info_struct *p, /* * When we get a swap entry, if there aren't some other ways to - * prevent swapoff, such as the folio in swap cache is locked, page - * table lock is held, etc., the swap entry may become invalid because - * of swapoff. Then, we need to enclose all swap related functions - * with get_swap_device() and put_swap_device(), unless the swap - * functions call get/put_swap_device() by themselves. + * prevent swapoff, such as the folio in swap cache is locked, RCU + * reader side is locked, etc., the swap entry may become invalid + * because of swapoff. Then, we need to enclose all swap related + * functions with get_swap_device() and put_swap_device(), unless the + * swap functions call get/put_swap_device() by themselves. * - * Note that when only holding the PTL, swapoff might succeed immediately - * after freeing a swap entry. Therefore, immediately after - * __swap_entry_free(), the swap info might become stale and should not - * be touched without a prior get_swap_device(). + * RCU reader side lock (including any spinlock) is sufficient to + * prevent swapoff, because synchronize_rcu() is called in swapoff() + * before freeing data structures. * * Check whether swap entry is valid in the swap device. If so, * return pointer to swap_info_struct, and keep the swap entry valid @@ -2495,10 +2494,11 @@ SYSCALL_DEFINE1(swapoff, const char __user *, specialfile) /* * Wait for swap operations protected by get/put_swap_device() - * to complete. - * - * We need synchronize_rcu() here to protect the accessing to - * the swap cache data structure. + * to complete. Because of synchronize_rcu() here, all swap + * operations protected by RCU reader side lock (including any + * spinlock) will be waited too. This makes it easy to + * prevent folio_test_swapcache() and the following swap cache + * operations from racing with swapoff. */ percpu_ref_kill(&p->users); synchronize_rcu();