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 7E1AAC5321E for ; Sun, 25 Aug 2024 23:29:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0A5648D0038; Sun, 25 Aug 2024 19:29:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0544C8D0029; Sun, 25 Aug 2024 19:29:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAC338D0038; Sun, 25 Aug 2024 19:29:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BC3D68D0029 for ; Sun, 25 Aug 2024 19:29:22 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 410801A060E for ; Sun, 25 Aug 2024 23:29:22 +0000 (UTC) X-FDA: 82492361364.30.A78116E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 1BEFA180006 for ; Sun, 25 Aug 2024 23:29:18 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=dYiZvETC; spf=none (imf24.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=1724628518; 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=6WmqFAxCOp6Wliq2cYkJz9GIAwrqWnHFntY1ZSayFFE=; b=UNdSdQ4vokskVuetfiCHFZUO/nOKJE0i5Rhin/zn3Fk9ygURBaWgQu9RGWIE0h38KuEqh9 GPdkEHwyKoZ/ePbKPrxhPa6pUIx8wtmuxrRYo0K7x60B1wNvuCJRhCmFAgEO1lz6rwR1st 2R4jrtcAIEmHLLq+PA/YLyFyshA288s= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=dYiZvETC; spf=none (imf24.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=1724628518; a=rsa-sha256; cv=none; b=NxRnZA1Kfl/1BuBmkjrNADqvuKzzl0A0OeuPgGEe0EGsayUsHjLcyHF5idwVrBpQ1eZ5s5 MftGZY90ZxQjt2bzOVIumc3uwFd++PwFJOFtcOUnCJB0l2rPwrg7I397w1GfPGitN0LL37 wvHlUIO+MGIS9BBdN5VQM+gdWjj9+H0= 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=6WmqFAxCOp6Wliq2cYkJz9GIAwrqWnHFntY1ZSayFFE=; b=dYiZvETC4JIeF5bkrobqpWY9EM G/NyA4FO2OhvvZD+d51CgYP8gk5PEZSzyAR0iT0AWEPdPmns7i2kppBtCdQOgUa66xAmCRsvhyPwA qea4zaYlht2arz69kk+wmQ4/Swv6fuQej2JLyTSXstM/xnnT2X4uhWDg319I/N1YUfe7dmvC+Mr71 GvSd4kkEM239V/M0w+HM8J4XQ+hNHDV91ntpS0jgsHmYSBIGIhneTljyp2ZWZSRcMBVmLtGnVSteQ bht5EzchQNJ4nXpW6Y+Evsht297TS/LLUlOmPmolMlZQ7kY8PljZPwIs6XGPTb6dokrksg6ZlXMr3 5bTpjo6A==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1siMfI-0000000EinG-2sB6; Sun, 25 Aug 2024 23:28:56 +0000 Date: Mon, 26 Aug 2024 00:28:56 +0100 From: Matthew Wilcox To: Hugh Dickins Cc: Baolin Wang , akpm@linux-foundation.org, david@redhat.com, wangkefeng.wang@huawei.com, chrisl@kernel.org, ying.huang@intel.com, 21cnbao@gmail.com, ryan.roberts@arm.com, shy828301@gmail.com, ziy@nvidia.com, ioworker0@gmail.com, da.gomez@samsung.com, p.raghav@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 4/9] mm: filemap: use xa_get_order() to get the swap entry order Message-ID: References: <6876d55145c1cc80e79df7884aa3a62e397b101d.1723434324.git.baolin.wang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 1BEFA180006 X-Stat-Signature: xziyofnsxcgojaptmxko1ipu9759ntxa X-HE-Tag: 1724628558-474172 X-HE-Meta: U2FsdGVkX1+9ykBaNvuw0BCD02Q5z5CMJvdxP351A1uUvxrMcKveFT7xv6MANHuGOmX0rRx1RcXldeoR1LrGGT5HrlT6aget9AMU55tfe2Sz32dpxpzQpF1M0z8shDXyCFIefukczXVKVYvByTcf/o5z3pfzNOygJl5eEnD+xu4dLJ8bTwcMgEfkEWy9jXURGLFRiVfkRA7DlzIzVGa4rvt4p6ug5p2/vUFQf9hT2wN81tLzJNQ7M7umKdYEHOMCA3HwU5jAyIO6lOMlMCWcMJrCkCxJ4bMv/CX677OlA6z597zAUfrzp8D6QfN4QyTd4lB6sdZZnQvaUitzDuMYBlbNwfs2RZJhUTp0nYg08Qf0c8pNsdSCh8h0nd262GKoqueIMhCzlIeOl9YJBeb9BVP7vgFAtfsTdJLINVJdfaMDqHSe5kG9sb2KtwRj9bFzohwbyIv3/cqNhfdGiTC6uF9z/qGV5zpdzrYjncjNQN4t5itdnYC1MQMi3hG9IkBd/e7pJxax/vw7hZRyShgqW1OZIuL98MQwuw6qimcZraZahlAuAd513g25PbvxU+RY++3ZOLvcLishIYH7LhsL8pAzlAcnlFkIXhfn6Mu577vlX0uepXhDpfi5c8rLFQQnihQe6TSScXLi6QydOOYZzCpHMxPOoOWCv9cx8NznKFWG0ZFmB5FMJGYUOouEzJtkUsniNwWlGZw8rPI8FTrxqVzZss5ThuVyIFuEJR9AKzdrPpyyJK8njl/xS1Q8sM2KDrQCfs0T4v9kJX+zh2pLdNgQ9zHitChqk+5ECNhm1myns8va35orgnDj7ax341TRiIuRfS6u37LvCQqlSxI3/YnIrf21nCNmxKXqfzkKBPZBun9drJdZQYvuUMvMRxBT9hqASEgh+b2e2Zs0xTd7EWzcakPgQyVF+PH+K0xyca6e6LIIgWgbgB+9twxjF7sL/Aiti63WN+A2aTsqZGA FOCTKy/s /5+tlzX+mbvTNnHa/WTm5EtvuWfHi/VufaZTUVqeKkdhiSVKyC37cyYRsJb5y1X2MDwJxqkoSdaaCUk4Fgkx446o2fGodgrH5RARx7aKqkN9Ig2QxnWL8+19iq+JBJ+dY6a7IvMAr9yTJh6MV5ArSmp2jiFLdxrQE7uZNyNDLVz0kCDS9I3jDKp7rdAc6jqLjbA70VsoD49PrvUPFxOpFFmAwKL5OO2aK5u2V9DmoPumXFocbrmcvnxEJqEHaL32WwvUV 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 Sun, Aug 25, 2024 at 02:55:41PM -0700, Hugh Dickins wrote: > The second issue is that swap is more slippery to work with than > folios or pages: in the folio_nr_pages() case, that number is stable > because we hold a refcount (which stops a THP from being split), and > later we'll be taking folio lock too. None of that in the swap case, > so (depending on how a large entry gets split) the xa_get_order() result > is not reliable. Likewise for other uses of xa_get_order() in this series. > > There needs to be some kind of locking or retry to make the order usable, > and to avoid shmem_free_swap() occasionally freeing more than it ought. > I'll give it thought after. My original thought was that we'd take a bit from the swap entry in order to indicate the order of the entry. I was surprised to see the xa_get_order() implementation, but didn't remember why it wouldn't work. Sorry. Anyway, that's how I think it should be fixed. Is that enough? Holding a reference on the folio prevents truncation, splitting, and so on. There's no reference to be held on a swap entry, so could we have some moderately implausible series of operations while holding only the RCU read lock that would cause us to go wrong?