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 7D159C71136 for ; Tue, 17 Jun 2025 13:47:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1D3F26B009A; Tue, 17 Jun 2025 09:47:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 184436B009B; Tue, 17 Jun 2025 09:47:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C1B66B009C; Tue, 17 Jun 2025 09:47:33 -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 F254A6B009A for ; Tue, 17 Jun 2025 09:47:32 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id BE96A120272 for ; Tue, 17 Jun 2025 13:47:32 +0000 (UTC) X-FDA: 83565019944.14.8B62BEC Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf26.hostedemail.com (Postfix) with ESMTP id 8294314000E for ; Tue, 17 Jun 2025 13:47:29 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aKXfCF5a; spf=none (imf26.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=1750168051; 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=lcPJP3hUDIFtPx56TulVw4D3uKiGLoVqKD7H4NXpVQA=; b=mhPyhgg5wX2JFMPHK2+mEA2d4uhvLzTkppiT5oVhQkbwchuIEEywlj8KHP0IXQXC4tMjGG A3TmlxXi1M3sb3xGYePoIoXQNg6ZRfieRdikUlZn6hpBNB25yzIGgcxcqjFEn0Tr+aJakq wGVoQEW/owU/LU7LuR+5NTqZVuBenZI= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aKXfCF5a; spf=none (imf26.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=1750168051; a=rsa-sha256; cv=none; b=GoCIU72cWIJ23vDEZngn5vK/vhVMOzqnXq63PChabbCKE/JWVcM81RGZe8JPy+wWaCzktY tOhnd3u9+u4dY46hpMGPUKJsJt3SIpwfbTiKQV5F9fbFIqb1qyqFtNI7l9qdct6jVWj1Dx K7hEn8Ih+8AJHyZViTtz/gVqytMiCpo= 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=lcPJP3hUDIFtPx56TulVw4D3uKiGLoVqKD7H4NXpVQA=; b=aKXfCF5aYa5NhdK+Fz0QNYVFGD oYDkUtaBYrVAP/Z64R5DhPmIyTEVtyfDTeW0sMRDyPr/M9N7Qhub6kclAOpa/gHa/M5if8aHsRRNF Ky3kuZEa8D2BhUm12cMySm4gs12suXCww+PtwDewVllUJFbrcjVgumHSdx83Xg6q46rmrnMpSQehu KeHknMGdhsTig3oyNok7FggQB6eWARdVoEyQBL/EnLnhOUNA/QK+lnnzajjXmeDMnuSvWMD9Zinb4 68ShOY81fiSMrMPrOGvKR2tFJyvQ8uITRW6zaiPw86DtgxlAWmmxzGlnoO0Vu+XKzV5SjnjNviwDf ogg+Abyg==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uRWep-0000000HD4X-28Z9; Tue, 17 Jun 2025 13:47:23 +0000 Date: Tue, 17 Jun 2025 14:47:23 +0100 From: Matthew Wilcox To: Dev Jain Cc: david@redhat.com, ziy@nvidia.com, dhowells@redhat.com, hughd@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ryan.roberts@arm.com, aneesh.kumar@kernel.org Subject: Re: [QUESTION] xas_reload() in iter_xarray_populate_pages() Message-ID: References: <20250526063524.22597-1-dev.jain@arm.com> <918d552a-085a-4529-8f20-a060b1f0c9f1@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <918d552a-085a-4529-8f20-a060b1f0c9f1@arm.com> X-Rspamd-Queue-Id: 8294314000E X-Stat-Signature: 975em48gfqh8agfaaeai6jjc7up9bytk X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1750168049-213514 X-HE-Meta: U2FsdGVkX1/K1MCaqhPhO/SkZlARypd3GlffTWZe63B8NEIpPyl7clEz/MdVayrtJcR9f6PfxdPgcoqXlKLoJnnxA351sp+nc7UVOSg6ulqKLajMxrY+gyeFgfZ6DzdmytsR6zwl7GtWH+a0j6kkliO4Kp5syxXpgppELkIcHUiXxSbTzGCBVvTDwQyzi/mE3Tj3AgiAxEVKNpBe61+ZlOLqUIrdGISmKDfk8xZKVSmaXMHoJXaR7HuEYODN4IlwX2h1s6XoprXLK7m1EJ7NfDbM/hz0mK+S+NfygCtSAuFW+KJ5qGoJ4kg4J3ICPac3vzbLG49QQwrsCTxsf0dB1NoZ5mDlvAdM9tE4wkBKYpKndAkxffLIX/aZCimscbIpUqX2Wdx6stD8u2KEYLxyKSUvryqx9TYt7DQzRRVvDuVFinfb5Td8eZJG+wipZOrYRfDq9TOKp8uR4SioxmsWdR3s8raiFxI8ct0bkH8suMX3OYL7NGNhpR8xXWWOJHEdgQ1aBtAVVkI35ZQUN3nUrGR4KUt+lY2xRvYC+Q+NMaGx2UINqobu95OP9CWQWxuN+UYKYvZrUL1T2yHI50OMaxkDXNkrDXQ7+4mU7D55ficNaxazUVZoMRTn3tFRMWim2BNOCFOFBhwA+hX5tHOCklN5Gn39+V5nKMk9o/+20brpLka6ZyHAyZjwNqJCFZPq01dIHtJ+f/5vJw45RsmbSVgjbZOU1lvqqpkEOiPIjP5bMkxocxwtJ10IDLd0Ky7Qmc/kRswsBfEDNc3znSI16DMlosIweWjsjVhiOySOsjGa2nK1LNaJlwfjr8fvbatjc5FY9yB0u5+wUHyXOxT0L81P3otaGeqtbQ/KbkirLnsEQD8wkJb1x0ScnZGhFj5X60j/c5tBKhNT5Xnq/thZsusExHkVXfzG4MkMObWMusGaDlpcB7nHXFY68TbT+z8IBjKfymCgVZHBrzFlGUq Y8talKv7 rylxLNKsXYO3l76Wx7Us7QqrDE6g4uGnFfmzwiufzUTwzF1sJvXIRhUc4Xs0OKc/uyyQviYCF0/yQb+k9r9tJ6vPgqO7sxZXiMfvzV0P7XU1Y//fRJvfQpIxvXtAlnLGJ23Ug/SbY93oAmbSm/lHwqsF5NUWiX/Qf2LFDkzFjx5IRBi08SQJz49nFmRafhbxwM0SQDllWUljzLMdC6UYmouv+1kKH3X+fJckFslUlxt40lH6dOkmuBcsg/tPYGFjdXY0698JDFR9uAJr3mc4jpN44sA== 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, Jun 17, 2025 at 10:40:51AM +0530, Dev Jain wrote: > > On 26/05/25 12:05 pm, Dev Jain wrote: > > Hello all, > > > > After doing an xas_load() and xas_retry(), we take neither a reference nor a lock > > on the folio, and we do an xas_reload(). Is this just to reduce the time window > > for a race? > > > > If the above is true, then, there is a negligible window between xas_load() and > > xas_reload(), because only xas_retry() exists between them, so why to even reload()? > > > > Thanks, > > Dev > > I do not completely remember our discussion in THP Cabal; I recall David Howells maybe > saying that the folios are already locked, so it is safe to do xas_load and then do > a folio_get()? Even if we remove the redundant xas_reload(), I still don't understand > why we won't need xas_reload() at least after folio_get()? Because you need xas_reload() in order to solve this race: A: load folio B: remove folio B: free folio C: alloc folio A: tryget folio A: reload folio If A already has a refcount on folio, folio cannot be freed, and so A cannot get a refcount to C's folio. The other mutexes are irrelevant here; this is purely a folio refcount problem/solution.