From patchwork Thu Mar 14 01:25:00 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Wilcox X-Patchwork-Id: 13592036 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 A9E79C54E58 for ; Thu, 14 Mar 2024 01:25:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8EC7B80076; Wed, 13 Mar 2024 21:25:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8771480073; Wed, 13 Mar 2024 21:25:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7172180076; Wed, 13 Mar 2024 21:25:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 555FA80073 for ; Wed, 13 Mar 2024 21:25:19 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2C9B8A049C for ; Thu, 14 Mar 2024 01:25:19 +0000 (UTC) X-FDA: 81893901558.27.3C39485 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf11.hostedemail.com (Postfix) with ESMTP id C9AC940006 for ; Thu, 14 Mar 2024 01:25:17 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=I8Pgntdf; dmarc=none; spf=none (imf11.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=1710379517; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=Tp2I606bNY2F38wtbjp+lEaq3mUZCZWbp3gi5sYoRqw=; b=EYfJ0z4rA655Xhr3mVUG00rxnk1enxBLmfH8Tb3icSHmxrM0JwdAOxC/fEVTWzZMvj1bzQ CFyIUe7piw/vEkchNcuouO9zFpw3nYb+3Ld+MLnIzcb+8l6+Yu08o3nMml7fvIgyz4aqu8 pCcy0FiW4qy4olUqcQolxJzGvfvEG0c= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=I8Pgntdf; dmarc=none; spf=none (imf11.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=1710379517; a=rsa-sha256; cv=none; b=5lvBYKtEmPHwovJ/WLv5xUipVKSvu/9OjL0ZmQj3PHVbcRUotjNGo+6iqJeVp7bICPHD/T qtqM+eRB4qDQNfDcZsKxq2lCaUhwU959397K9DKAnrcTdXn18LhuDP2z59EuHMJiX9HbsE 7NlQsdz37bM/rcyaYxdzhye4L7JNhYk= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:MIME-Version: Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:In-Reply-To:References; bh=Tp2I606bNY2F38wtbjp+lEaq3mUZCZWbp3gi5sYoRqw=; b=I8PgntdfQPZo8URbopA4JdGOpB ce94RZTdmaHPXW1/g6JIuBKbXN7EYuts9nc7xEelCSBvcU0lvEvls6+sM2lpwzG3DJNHJBnjJfswG SR11qrHQTFO+zxwnCX098JUJVxVMrWKGK393Pkhcema2RMVh9huTsBjpwy5IVYhJkyg+f5CslTqpy /Q5fGt0OoIvXsxwYNuuC5EXV0y/9+7CZDOHo0UL7kIo3MM4wsdj8zmE9w8J1V0/QQppvNZg8Kypay LlxZ2mlvomTMxMMwJemOSOBEDb22dBxt03v3colGSG5T0hIg3X9gFXwR9cNPLiLoQSoBHRMR5MW5X Th1N1xFg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rkZqG-00000006iKt-2Yqg; Thu, 14 Mar 2024 01:25:08 +0000 From: "Matthew Wilcox (Oracle)" To: Andrew Morton Cc: "Matthew Wilcox (Oracle)" , linux-mm@kvack.org, David Hildenbrand , Oscar Salvador , Miaohe Lin Subject: [PATCH 0/2] Reliable testing for hugetlb Date: Thu, 14 Mar 2024 01:25:00 +0000 Message-ID: <20240314012506.1600378-1-willy@infradead.org> X-Mailer: git-send-email 2.44.0 MIME-Version: 1.0 X-Rspamd-Queue-Id: C9AC940006 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: rg8qd37onzmw7xpq6ny48u7bg4wso4af X-HE-Tag: 1710379517-402755 X-HE-Meta: U2FsdGVkX19wed2RvFlmJkpXLKFVdn2uUbOB5jOLDExGLnfZt3B11nz4R+RfbXAEFJNkUbcNFoDWPD9eg6Bu+cTwicX4MmcPOl9mh/taoK3cgRnZcqFwRhZcdlIF/lmvYhOJ+5J8+AsMsBXHYO2P3BIZfUfGi4Bs0FlAit8AAKlrR9DLCWIkpAgANJED03Dg4AjNTPcbC4zbad1GW0EyNCqalACYE55VkXFoc1+dlIMkYdUJVuxxHmiNF2SoOxp5WPwL8c7HJBvjCk/yLB7CG1RCko3QgMmlqBtFwH0iGTLfGlgenzHYzpzFuE5+3+R/v3Vv4RiB++9ZNK67pgACg7TwNnJgsL5PwQYGkJmXtBdkxqw+5y3RZmak0L9CCpRYkX7rNw1y7adLffh6frjHdfGBpzEb6fIDNIGG/GngiIveMZdE10b5pqnd8BwRC29FjsLCtC7020bRRm7fBC8H50O3molUD/qhDf7Ft6R30zwOV9H7Db2AdKhxUZoEspilsFbvnlNClXIM4YhtbD+0CUp05xQzQbV9QVbobVn81Pcky+94jh8Vl6PwoIyPKaaNrR1vHs5dCEr4xMQgdwJVg84gcZuAnOcAG26njefsR9eE+4YMtyGNFtM0mheHNZ5rhqc5qbBXT7Ap9HjcxH4qfwSIfhe9oeZNXNQ2pqwggFveYc98BcapP9GRFnmT4yjF//MSA0o6fOSU5GDLYG6GHTAWOwYxIIsX1MTkPV7600OFPuLKWrb5Z8MGQqJRloPUC/ISP8eycYWw7mZN69Lq/Ng8HteGFSKYRJUzLpW6e1cJ0smtrAbwL52fO8GQ4pKXZdK8v0kQUa58PFYHX/6+6bf3ECINZByXB6H7jV53IOSLpMNhWwFJzg== 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: We need to handle pages allocated by hugetlbfs differently in a number of places. If we have a reference to the folio, there are many methods which will work. If we don't, most of our previous attempts can misidentify a page which never belonged to hugetlb as belonging to hugetlb. It's quite hard to hit these kinds of races, and generally the results are relatively benign, but I don't feel good about them existing. Obviously since we don't have a reference to the page, the answer can be stale ("it was part of hugetlb when we asked, but now it isn't"), but that's very different from "This page never belonged to hugetlb, but we said it did". We've tried various things in the past. My most recent approach was to use a bit in the second page's flags, reusing the "active" flag. This is very susceptible to this problem. Before that, we used to check that folio_dtor (previously compound_dtor) had a specific value. This field was also stored in the second page, shared with the LRU. It was less susceptible to this problem, which may be why nobody noticed it since its introduction in 2009. We have considered various approaches to make folio_test_hugetlb() more reliable. We could use a word in the second page, but that occupies space that we probably have a better use for. We could use a word in the third page, but then we have to test that there is a third page so we don't run off the end of memmap. We considered using a special value in nr_pages_mapped, but weren't convinced we could ensure that it would be unique if the second page was reallocated to a different purpose. Using PageType is completely reliable. It will never return true for a page if that page was never in a hugetlb allocation. It doesn't occupy any extra space, and we have plenty of bits left in PageType. It's also the most efficient definition of PageHuge() we've ever had, allowing it to be a static inline function rather than an exported function. Matthew Wilcox (Oracle) (2): mm: Turn folio_test_hugetlb into a PageType mm: Remove a call to compound_head() from is_page_hwpoison() include/linux/mm.h | 3 ++ include/linux/page-flags.h | 73 +++++++++++++++++++------------------- mm/hugetlb.c | 22 ++---------- 3 files changed, 42 insertions(+), 56 deletions(-)