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 A738DC47258 for ; Wed, 31 Jan 2024 23:45:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 173956B0082; Wed, 31 Jan 2024 18:45:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 123836B0083; Wed, 31 Jan 2024 18:45:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2CB76B0093; Wed, 31 Jan 2024 18:45:34 -0500 (EST) 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 E24DE6B0082 for ; Wed, 31 Jan 2024 18:45:34 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B0DFA40D9A for ; Wed, 31 Jan 2024 23:45:34 +0000 (UTC) X-FDA: 81741240588.07.ECFC2BB Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf19.hostedemail.com (Postfix) with ESMTP id C7D591A0007 for ; Wed, 31 Jan 2024 23:45:31 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VSG2dZct; spf=pass (imf19.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706744731; 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=rauFdiPG885gHL3Kly07gfLuSPxr9bpK4vHslFE+EYk=; b=c0lsCaTB3h+pqBCay+hUQxfitLBbQ8KfU4IXzoQVQrff+cuJ24ed64BEWdr3CtS8+W7JKs DQTPvAYPXXYVEbq8mJkIsj2wI2Iy9K+bxCB5hCp5oJv+VSAADs2nY4emDIwGu1lWD7vEOp UUGy7KQCWaGB3Q3F0jrf365RRRhnmHo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706744731; a=rsa-sha256; cv=none; b=YiSMh7u6fn0xflbgxzURtVzCD3I4DyHjyU8rKXOMMRAx1WSd5K7/vyUtYCbazq5B/B18Qr RghNp4Bv7gA04s2K6NRBC0ijPU2C2HGVIuQKzR/t4If2m6R+QG98EGZdPUJm6af+z6rULq NYZL9qPoBwG8jbCC0cWdepjhZE5ioEg= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VSG2dZct; spf=pass (imf19.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C40AF618DF for ; Wed, 31 Jan 2024 23:45:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0AD22C43142 for ; Wed, 31 Jan 2024 23:45:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706744730; bh=rgrCgSpALvr1CWsUIFrHZh9N3HtW5tFrYXTts++yW4Y=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=VSG2dZctjU1VVVJzpFnw0HUzkXVWotnl9yhtM+MfzL2JzdbcQ4R8wBs+mj8dL+PqI gBfwF1oeHX4rY1b7LbDFv2ZP8bI5sglrAJCHhyKrw7jQdEnsxwhAsxV9Yhw8eMKjfo KqRNujtxhjW+OaU8xvR7mRjsFXES3dW7rYwSXQZ02m8SuBb6m/9epwiStAlVRad30K 1fbsQFaPRn5158VWH8EnXCbMvI5OuPIUowehO77vbIvKtIIuDR++UfkNiapO4w/pVB dsB+Crlr+bxRjrU3wfXIvUgwgzSkTBMm2rXVw4wbz2R1nXQmyfHjiIe81ABg/J+Pn9 0eiTy4GZ4lDQg== Received: by mail-il1-f182.google.com with SMTP id e9e14a558f8ab-3637d8ec873so1687035ab.1 for ; Wed, 31 Jan 2024 15:45:30 -0800 (PST) X-Gm-Message-State: AOJu0YwJj57V1mVDEjHS2vmfdWgrrpgNW+p4Wtv2zN9NVd1Vz4aGvQoA eTl/S0jAjMsuVLqigy1Edjyi0edmqIhD6sPVJdr2JQ52FqCRIdk0rC3V3RmTrPjUs9Pn1fCbm5k KoGCGi6lsxV+4/4G69xtfbKbxnrCZP7VPgc90 X-Google-Smtp-Source: AGHT+IHxIcPjPLgCEuO2FNMNke9aAioh5w/QeEIyl/LRy/szpWrbpAnYRI7c1RlsYBxcbDyJqlEj/OCh5XxkmjljosY= X-Received: by 2002:a92:cf47:0:b0:363:7dc6:a156 with SMTP id c7-20020a92cf47000000b003637dc6a156mr3162291ilr.5.1706744729276; Wed, 31 Jan 2024 15:45:29 -0800 (PST) MIME-Version: 1.0 References: <20240129175423.1987-1-ryncsn@gmail.com> <20240129175423.1987-7-ryncsn@gmail.com> <87bk92gqpx.fsf_-_@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: From: Chris Li Date: Wed, 31 Jan 2024 15:45:18 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Whether is the race for SWP_SYNCHRONOUS_IO possible? (was Re: [PATCH v3 6/7] mm/swap, shmem: use unified swapin helper for shmem) To: Kairui Song Cc: "Huang, Ying" , Minchan Kim , linux-mm@kvack.org, Andrew Morton , Hugh Dickins , Johannes Weiner , Matthew Wilcox , Michal Hocko , Yosry Ahmed , David Hildenbrand , linux-kernel@vger.kernel.org, Yu Zhao Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C7D591A0007 X-Rspam-User: X-Stat-Signature: ioki5mfdui4xcfdhem6zxb6jzh7aj636 X-Rspamd-Server: rspam03 X-HE-Tag: 1706744731-166429 X-HE-Meta: U2FsdGVkX1/7M5cJuDVnqqZ1v+JguuIuAEnFEcw4grMvtInxnWoiN5238K1kfZ3HpuEqC7ZL4YAyV8/YS4+3D15qZ2un+m9RsxONJGNvjvjItpmdY6VlJdgN9QCKPED3oG+0EnE6l5Z3oIqBVQqtiDZuhIrH3gg16YIHYO+REZX4jiPcYVonZx6we1dDoiWEsnOgvDWJx9zDOQvlqfrY2RwL//s+i6i9mTztZtZ5cFmJchKwEXwN++MGi+/tlwoinUI7HF4q3jMeRtk9NCno1fZ3XZfy/WFdLUzMmwn4aJZ7ng6kBkfY/A3/BQNgNon8b9YD80tf7dqpvgg13JwHADLjnajvRnYfvZAR9tktK53uNQ/w7WtAOSUmHc07F4DzxamBUjoKtw64p3evkwW0bX2o7fBM3vtIN+b06zFoO/eTaCzi49pRP++LBQ7GM8agM3yhcs2m/q4gIFk1MYwTT2aqMYddK4NNnh+YrEF0UE1O3Um6ifXaF0xi/V1AsSIOswFguIrtE1+0T1vlw6Lq6W6Jgkczxr/gQaoP9Kekw2c6WIvKpMCP9XGCPTVMpGcq3uQ5dzF1Z/werR85EbKH8jYL6Pq9DgLqmBOxolq3eh1xn4tMKzCh1QkL6PlJCvzmEbQ3L9VuT+ZCOACTwYhWY1iBI9sizPPkULBa4PV4b5ScnyFLnMgv7ko4SmagXWyNbQLfJGbcML87eXu06aCs+mXRjzRBRB964wyGZK40bVWwaNIarxWa4cHmlgXWgbZQFk7/lnplgqDLBkXTuTSBC7N95raEF1ssYnCU6215LJjpQ5N3gWfdzu7esjtcwrRQbo5iqcC6jBC5z9pjMnVzWcD1jYE76obFkfjQo4+dXQnlK6TejYXaIuZ51irRTugNDgWyPAMH3gISa90aUq1HSF0QrVDdlqpT9A9n8nVzDPxpSk/6coxP+Rb0g88Bx8IgVJMQdmCdOKaXG1CLQn7 muNWeHzE fWqzBZ+8nR1nLNbU0kuyl5AGKAsdyulfq5qrbtLGBupXhfdqSVwLHTIW2xg+CHkSKx5ofelvSnnaKz+Z6QeLkiZMCU2rI26hLFnwTdNpsLbpBXb+4SPLEQS7zrpUz+IWsw4Db717UZsfFuL0VW/fCZwITTvjDRkgx++M30RNvhRxZwz+I1CkuBILg84JseEgIaCdX0JvS9b9nyv2mX7y2dRaKEg5F+T+xYs2YOEWNRlpnBvDGsWZyVL8xASuWb2u1SPQFN9kugM/HsuVGGShD8VHDAPPapJT9dOX5playFVo7/u95YjYiyXjygMdFszQwJ1T2GajysJhjI6/D5rTY3lhEvK0wADIRVKku13aTc2ui5qYWSnWHf4PuVj+fs3JRXfmtj+VlJ7GPScvSDyvEX++4a/H+XnlwrDsG 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: On Tue, Jan 30, 2024 at 7:58=E2=80=AFPM Kairui Song wrot= e: > > Hi Ying, > > On Wed, Jan 31, 2024 at 10:53=E2=80=AFAM Huang, Ying wrote: > > > > Hi, Minchan, > > > > When I review the patchset from Kairui, I checked the code to skip swap > > cache in do_swap_page() for swap device with SWP_SYNCHRONOUS_IO. Is th= e > > following race possible? Where a page is swapped out to a swap device > > with SWP_SYNCHRONOUS_IO and the swap count is 1. Then 2 threads of the > > process runs on CPU0 and CPU1 as below. CPU0 is running do_swap_page()= . > > Chris raised a similar issue about the shmem path, and I was worrying > about the same issue in previous discussions about do_swap_page: > https://lore.kernel.org/linux-mm/CAMgjq7AwFiDb7cAMkWMWb3vkccie1-tocmZfT7m= 4WRb_UKPghg@mail.gmail.com/ Ha thanks for remembering that. > > """ > In do_swap_page path, multiple process could swapin the page at the > same time (a mapped once page can still be shared by sub threads), > they could get different folios. The later pte lock and pte_same check > is not enough, because while one process is not holding the pte lock, > another process could read-in, swap_free the entry, then swap-out the > page again, using same entry, an ABA problem. The race is not likely > to happen in reality but in theory possible. > """ > > > > > CPU0 CPU1 > > ---- ---- > > swap_cache_get_folio() > > check sync io and swap count > > alloc folio > > swap_readpage() > > folio_lock_or_retry() > > swap in the swap entry > > write page > > swap out to same swap entry > > pte_offset_map_lock() > > check pte_same() > > swap_free() <-- new content lost! > > set_pte_at() <-- stale page! > > folio_unlock() > > pte_unmap_unlock() > > Thank you very much for highlighting this! > > My concern previously is the same as yours (swapping out using the > same entry is like an ABA issue, where pte_same failed to detect the > page table change), later when working on V3, I mistakenly thought > that's impossible as entry should be pinned until swap_free on CPU0, > and I'm wrong. CPU1 can also just call swap_free, then swap count is > dropped to 0 and it can just swap out using the same entry. Now I > think my patch 6/7 is also affected by this potential race. Seems > nothing can stop it from doing this. > > Actually I was trying to make a reproducer locally, due to swap slot > cache, swap allocation algorithm, and the short race window, this is > very unlikely to happen though. You can put some sleep in some of the CPU0 where expect the other race to happen to manual help triggering it. Yes, it sounds hard to trigger in real life due to reclaim swap out. > > How about we just increase the swap count temporarily in the direct > swap in path (after alloc folio), then drop the count after pte_same > (or shmem_add_to_page_cache in shmem path)? That seems enough to > prevent the entry reuse issue. Sounds like a good solution. Chris