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 62DC7C54E5D for ; Tue, 12 Mar 2024 15:38:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E49118D0056; Tue, 12 Mar 2024 11:38:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF7518D0036; Tue, 12 Mar 2024 11:38:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBFAC8D0056; Tue, 12 Mar 2024 11:38:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B37348D0036 for ; Tue, 12 Mar 2024 11:38:40 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C5A461C0BB8 for ; Tue, 12 Mar 2024 15:38:39 +0000 (UTC) X-FDA: 81888794358.10.F96C64A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf03.hostedemail.com (Postfix) with ESMTP id A5BE620018 for ; Tue, 12 Mar 2024 15:38:37 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ul8xkCgI; dmarc=none; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710257918; 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=kleRq5Aq4AM34OoO49dgZN2BK75kCCtY10+hmxDg0YQ=; b=XSalawYqpLFviA1jcjvg58VW7cgFD2qMltDNIshb9zV5RBSsWU/xPfj5EsoaMwdFuk9X00 zKSo31OLPQnz2b0EGmhx0wew8ys09t8+Vkf7SyYqHQrJ73P2HSF/hUeXCpiagWHm5Av5/v IOuxJOeflrLKTLOkxNoitom7hKGeyEM= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ul8xkCgI; dmarc=none; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710257918; a=rsa-sha256; cv=none; b=MiaaxH4N9K9h3SfiNt+vvHJneW9VWCORqBd4+BNnPwvvTOsrk1yiUI0vvrwaHHz2kZvOEr 4GM0GIlCBWn6jRZU42Q0AW5dCxNSaOF/DRetyvG9aW5KqJazheKTebJV0PRKvRt47IiVoe uJTYs9NaDqLiMoVfrPgR8YlBT5ZzCDw= 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=kleRq5Aq4AM34OoO49dgZN2BK75kCCtY10+hmxDg0YQ=; b=ul8xkCgImPgHSwm/IsbrLRurWy uJRG9njDx4PHMKD4m/BC9FrWPp7Z7ndOGRnOytUjCk4SSujqilWTWyN8Ldlprh4bAnFvd/GRklEG6 lOKYL5JR6COmvee7HT401OwFJsisSPm9cIGUt08LkAtf3EVtsggP6t1kc70f8sbJ1wqSxx1sKK41G DvOqeQxXYwEThZTFk+78y0iNn/JXJsf8iGiYnDFkQqMfpO0ZqgI2zt/ERGqEsb/P/r+mQMQpB4T67 M0CUzAFyNbxuKkLFwCx463cwKmI0hMSJeK+VKTrs5WGMf5UQ+6CFYLy5E18Nml1tWVoyQChh7uIPv xcJ7N5Cg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rk4D5-00000003Jv8-2Ot2; Tue, 12 Mar 2024 15:38:35 +0000 Date: Tue, 12 Mar 2024 15:38:35 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: Andrew Morton , linux-mm@kvack.org Subject: Re: [PATCH] mm: Always initialise folio->_deferred_list Message-ID: References: <20240312035017.516865-1-willy@infradead.org> <78d1e235-b055-48ce-a987-e8719163caf7@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A5BE620018 X-Stat-Signature: f79mcu7w9pcyduo9etfjfd8hkajdrat8 X-Rspam-User: X-HE-Tag: 1710257917-903053 X-HE-Meta: U2FsdGVkX1+rBXiHNkrAbkUQVGk64/TUlaG4Lu2dHwf+lrtWFaiIr8470ju56EM9hcAn6pXhrM0sUCnu8tqk1xnqmhb2bnlfmeGdnQDCbifb4BYuU13y2bwDqUfVEipkH46Ih0fMY5UtQRt1WxsNKuN80fs3FqkYlLRAY8KM3jaoTMgbFEInbK/XCkFnAlaVBBbA6EJhNZS/S4CCi0ePm1uoNbr+rdDp9hc31mKx1xQJwrem2m8OdWRTwZNe0rXtBR7w/WgiqCXJPOoOZK+CM+rDRAwQXP2K/fet6rWOd7GROwRqOAOBVAvPcbBontd4743SR2v/hHOU2jakL3iDdDl9HloFoX8qs8oxuwlQerBQAyma2S0JDTgCvJJ8txxpje4MFbMbnJ+OkiCvu6wNyM/9YnqHryTKmaCBWGkpPA/CBIBxKAe4a8/BgienZJKkOsRUYs0jYT62JVovfUTHJi7uwMIMSX8yaH6gR5umNB81DQ0yK1v2KpPDqJvoeEbX2GsVtFIWqMsDNIsbkyXRk5cWSMQYti3YnmyUS2VlZ2ACtzqLYoVG80hl6LbJAcPeJUSXvdZS4p63IOzvq3RJcA4SB0EiLeU/FnaiTLsskF/yg/Wy7yvh7U2DkPiikFDeF7UigTLb5udvkgvb/IU/xXn3qjj+o0IgrP5m4F/nRaFdpyJivXuC5X28QHBuHIknPdXejK3TPskFYZ+fc9OskMtxmPAwY3KxmXte0Ub2hvW9UDIbMib2rjGm5yLdZmDOltR+YlAjvtxzeEui28cAD2v+lhBh9pW4fXQ/jY2vgkq+8QcVrYg1X+onkO4CCpBjuIZSe9PbjjdaWAbHR1yKEtfbro2yikR/Iw23zhnZbxKylXLwTcDZGZ0xB1LaJFqc 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, Mar 12, 2024 at 03:34:13PM +0100, David Hildenbrand wrote: > On 12.03.24 15:01, Matthew Wilcox wrote: > > __free_pages(&folio->page, huge_page_order(h)); > > Heh, __free_pages() says: > > "This function can free multi-page allocations that are not compound pages". > I suspect that means "can also free compound pages", but it's confusing. Sorry. I wrote that documentation and I was focused on one thing, but failed to think of the other thing ... it can indeed free compound pages. I'll add this: * If the pages were allocated with __GFP_COMP, prefer using put_page() * to using this function. Also prefer to call put_page() rather than * calling __free_page() or __free_pages(page, 0). > Especially, I thought we recently learned that free hugetlb folios do have a > refcount of 0? Confusing. Yes, that is confusing. This function wouldn't work if the refcount were 0 (put_page_testzero() would complain). Ah, here we go: In __folio_put(), we know that refcount is 0. __folio_put_large() -> destroy_large_folio -> free_huge_folio (refcount still 0 here, indeed it asserts it) If we add it back to the pool, the refcount stays at 0. But if we're removing it, we call __remove_hugetlb_folio() which calls folio_ref_unfreeze().