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 D7EE9C54E67 for ; Wed, 27 Mar 2024 12:31:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B1F06B00A0; Wed, 27 Mar 2024 08:31:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 662C36B00A1; Wed, 27 Mar 2024 08:31:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 550986B00A2; Wed, 27 Mar 2024 08:31:58 -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 383096B00A0 for ; Wed, 27 Mar 2024 08:31:58 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 01EC880D42 for ; Wed, 27 Mar 2024 12:31:57 +0000 (UTC) X-FDA: 81942755916.09.029EA92 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id 334494000B for ; Wed, 27 Mar 2024 12:31:55 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=vnlu+KBx; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711542716; 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=NLZi73Xb4ep908R2UXV6rktiIulOxpZuvd/TS5KeEy4=; b=uNge0VNH7n06+QxNeu0Zu8Ql+tUwusm6jWC4lISWU+uH35wMQ3S/wwRPGaY/KEiJqhlQVc dqVcHhwcdX0yZcNqG0QMEDA0mH5DM659tQ3DUxkBdYCaVA1a9NfPbRP0YCEWinwV0aBtDD 8n7SakW8ZWtt84IS0/WOvIM6FcyyHmU= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=vnlu+KBx; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711542716; a=rsa-sha256; cv=none; b=hXH8ZbdXSeftKg5dbwafiA8LnqzUpk0QcudGhJHJGkEDOt9IbACQcZ8QU9QXxudhthdIc8 FRikcVJhyuS0ItvD+kzLeSQde/vo7S0y8d/+QeXtr4JcXbMN7xB7rcEAe5WUHcwI3mkrqH Ij8PwmTW67ptg8EbnJXxgLws9QPljfA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=NLZi73Xb4ep908R2UXV6rktiIulOxpZuvd/TS5KeEy4=; b=vnlu+KBxz0A/LWrNCJWqk+pOMj FqC3Hme8EZRafost80noqjORFBRzKICIGLAvtFPgVKInoFqzVbb2gB825R3qGetjUztfDMzH6RjFy RmuGURgTIWwtHoOo4P5VMwkcJe1iSxTbg4feNAf87bl4RKYxSTwq6YRr2pwyPO7ZFtdgZDc6S5Nej 1AoZaOlltlgWw3JirOg9Q2jlR/u6lP2HODPT5J0t5pMZB2pEYhbJ1cY7YIG0AoRkpDHnDDSRIJ1ES NZSeiL9wxmjtgFnjaZs+PHZQDxgTWE+wf32ZAcozbJ//v14kiyVDGQSmp1n97hWkY4xKA4aHM+haC OixDqVuw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpSRZ-00000003qY9-10f2; Wed, 27 Mar 2024 12:31:49 +0000 Date: Wed, 27 Mar 2024 12:31:49 +0000 From: Matthew Wilcox To: Zhaoyang Huang Cc: =?utf-8?B?6buE5pyd6ZizIChaaGFveWFuZyBIdWFuZyk=?= , Andrew Morton , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , =?utf-8?B?5bq357qq5ruoIChTdGV2ZSBLYW5nKQ==?= Subject: Re: summarize all information again at bottom//reply: reply: [PATCH] mm: fix a race scenario in folio_isolate_lru Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 334494000B X-Rspam-User: X-Stat-Signature: bsmn3dbsfgi5phg9wfxkpoubb8qactt1 X-Rspamd-Server: rspam01 X-HE-Tag: 1711542715-37410 X-HE-Meta: U2FsdGVkX1+ntWh0N5Hebom0ZOPGUzvhr8Hiir+tNaVJRXfGrGiaCGu2c6Y+d6S4iASlanUkM4F6El5JHAy5uKX3R7neqOhwvomUBspeQmKU5e3mRNew5RacIeXor35aI1FyNMRcmrlLpm5AooBkklt+ukRZz5NX3psyUmJD3M1mfByW7YNCb2j7bzWA0eNt8P+GWv1JIfMGQxSM1LYq3Zygtl2tZ+Xu4vl2+A+kVfPypgIaX/cRGpya2524DeRcvgVnyylkIj1+jUIJswkfQgIz3jiq4mjbVRI3ju/svDTw6yJ6EZV5dSeS50mYxcjaqvD3Iud9EzBxSzaCGqz6Od4WkSnEqfQX8wc2lBWudNjgk96r526zV0HymK+K/uQxoJ5XPlzKM5TNqka1VhH3wp6k/v5/nMMhwdkldqeGhKFKk08a180p3iWi7itPXuQAwTJriU8hqi8gqkzWfwMYHxcO2LNhdJmwFUiY1QOg8GoBT7AznmYZyN+rx8Z4Rj0NGIQ+zBvSJwH+ItmLy6pbNnFkFcKp7GA+17IcPbs4mk7+H5iTjgQuPX5aK0SvzxRAgrRoi0RQ8zl7qg7suGKTuIZYS6fiLQspO/kiVyec/gxM5WHROtx2Wmk9RSYuO//WM5RHES+4VnCL5sLU/5spbk9l7j8cajnnaLb0Z0yCoG+9oMB1s0IwzCyMwLZp/7sdJULwn4pWBdsetsYcdziGH9b8Sm4PDX6tJ987wiM1PniU7niZxv3BrGgsdt+o1TbjKBj//kkPLO51jB8ggjzh2uUGra7bd36pJdKTv/0A7FOtDHZWM4ihlllSH/lhNtZCoVi9tZ9KEq91G7FgIXrp4W2Z1QtYlmmmv8zX/VZ07De12kLb8iFyK6UqO3ZvwSCmMngjw8aqBXXZ3hsQG9uwc625FyS36wTwtAMc3Kyu5mB4H8gbxTprrqomL/6TQ1uOoNPb21pZz2E5wWTWNmp 2yx3f4p9 qpAdLLRrifUXd5JntTqSbLX3Wa72BoX6QlsN8yBV3NhWFuW91B2Mwt5DiXRFqcPJmlsGr3Nq5PH6jaJ+66VGeO6Zdv2/grYejTsfPTijadQXVcFYDXezvI4Il7jM/nwSovr/mmFglguTFGjNn3BlJX5z/t5B64X4giYI3F0+yT1WSxqgxai2I+RQU9AcJUUiMlEbp7UvWyyavg0xi1vj3YAd8Ey7GUJ47VyiZ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000014, 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 Wed, Mar 27, 2024 at 09:25:59AM +0800, Zhaoyang Huang wrote: > > Ignoring any other thread, you're basically saying that there's a > > refcount imbalance here. Which means we'd hit an assert (that folio > > refcount went below zero) in the normal case where another thread wasn't > > simultaneously trying to do anything. > Theoretically Yes but it is rare in practice as aops->readahead will > launch all pages to IO under most scenarios. Rare, but this path has been tested. > read_pages > aops->readahead[1] > ... > while (folio = readahead_folio)[2] > filemap_remove_folio > > IMO, according to the comments of readahead_page, the refcnt > represents page cache dropped in [1] makes sense for two reasons, '1. > The folio is going to do IO and is locked until IO done;2. The refcnt > will be added back when found again from the page cache and then serve > for PTE or vfs' while it doesn't make sense in [2] as the refcnt of > page cache will be dropped in filemap_remove_folio > > * Context: The page is locked and has an elevated refcount. The caller > * should decreases the refcount once the page has been submitted for I/O > * and unlock the page once all I/O to that page has completed. > * Return: A pointer to the next page, or %NULL if we are done. Follow the refcount through. In page_cache_ra_unbounded(): folio = filemap_alloc_folio(gfp_mask, 0); (folio has refcount 1) ret = filemap_add_folio(mapping, folio, index + i, gfp_mask); (folio has refcount 2) Then we call read_pages() First we call ->readahead() which for some reason stops early. Then we call readahead_folio() which calls folio_put() (folio has refcount 1) Then we call folio_get() (folio has refcount 2) Then we call filemap_remove_folio() (folio has refcount 1) Then we call folio_unlock() Then we call folio_put() (folio has refcount 0 and is freed) Yes, other things can happen in there to increment the refcount, so this folio_put() might not be the last put, but we hold the folio locked the entire time, so many things which might be attempted will block on the folio lock. In particular, nobody can remove it from the page cache, so its refcount cannot reach 0 until the last folio_put() of the sequence.