From patchwork Fri Mar 1 21:47:05 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Wilcox X-Patchwork-Id: 13579166 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 495EDC5478C for ; Fri, 1 Mar 2024 21:47:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8AD816B00A0; Fri, 1 Mar 2024 16:47:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5EE426B00A1; Fri, 1 Mar 2024 16:47:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43E866B00A2; Fri, 1 Mar 2024 16:47:26 -0500 (EST) 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 313436B00A0 for ; Fri, 1 Mar 2024 16:47:26 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EFD8D140583 for ; Fri, 1 Mar 2024 21:47:25 +0000 (UTC) X-FDA: 81849806850.29.7839CE5 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf10.hostedemail.com (Postfix) with ESMTP id A7550C0013 for ; Fri, 1 Mar 2024 21:47:24 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=sLVEJXac; dmarc=none; spf=none (imf10.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=1709329644; 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=PxUcCDZms+hDUOLTH40LcOHboveupmjqbkpNZHqwD/c=; b=VrPfnqv1j3Eb8Gc9jWBGuWUBuNHqRuFmwgqG6b6lxqIXla76TVcgZJOSFzuAlycNh05bSF AlImpEy4FR1IrEFPCof1InJT9d52C0xebdVdNq9prINDb2krA7osxoGvYTAeSP2xXmSC5m kzbNyVmHvHwELNMVbOp3ybVNo2HjA7w= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=sLVEJXac; dmarc=none; spf=none (imf10.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=1709329644; a=rsa-sha256; cv=none; b=jejJz/AuauSrHNX+sHesMeJMq1inPGa/PCakOnxspmbLCnCyhxYLKhIRstxrPjBLLCEgXB UrgsmqiLfvnKfhzt6qLgR6vMkVg+dRbfbGfLbcndBn5R50VImYX31A7FNFzotEb9pxK2CR IXpYmFwkwbBw+/MmleZD8THidgInfoM= 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=PxUcCDZms+hDUOLTH40LcOHboveupmjqbkpNZHqwD/c=; b=sLVEJXacKgEDQkNl5nsK9KCmYz DdTkZpUQ8YWRA7VrLBRqbQ7phaOD2CML1ME9IJmAvs/RM4YcFxLM/yQiSPkKjcIm9q2O/2eybr+6w 9lahzFoOAuo8RvwhAxCEP6wyYRaoKtUMY4lQzcGSi1HLSomZmLK2gUl4iX7oHOr8j/ClGfibrcmjE 2SqG6XBzVY5i/DDgRLkcJKXkobJXo/NKH2LhZD81io4CQfTVkPlMX3+wCODIbCIjJJ39pMgwlyJsb /eYnFXrRaqgQRMes7eTlDAXiD5Zt0ODscffiwbdtw2nSHc9wP1NPXKTJrKbmR2lzXy06foBiEl7HU NTuW77dw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rgAin-0000000ByEf-1PpM; Fri, 01 Mar 2024 21:47:13 +0000 From: "Matthew Wilcox (Oracle)" To: linux-mm@kvack.org Cc: "Matthew Wilcox (Oracle)" , Oscar Salvador Subject: [PATCH 0/5] Remove some races around folio_test_hugetlb Date: Fri, 1 Mar 2024 21:47:05 +0000 Message-ID: <20240301214712.2853147-1-willy@infradead.org> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 X-Rspam-User: X-Stat-Signature: nrcqxn9kf5qo47sm37jbca433px5pp5e X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A7550C0013 X-HE-Tag: 1709329644-850467 X-HE-Meta: U2FsdGVkX18hkbf2Rjp0UJcsGBR3qd3zhwYQI4bhLMysQY4hJ3x/h0cTfpDJY2axyCOcRCO+Ub50IIW8R+HHB+4Hirwehixpxi61LMWgoDM6793US5Xo7iMnGa0l0fkFlhQOEUOpSs2jAqGl38gV9g9HmOJ3H4+g03CwdzMCBtfH7JNqY5nUSie1gGt9KlkVN5XmFJBH37UcWuNYF/hkczbRELnrS2nv65pisqGDkfh/3R+Q6sXeiIXqQS3F+s2tEy8d7SEWBz73lvRTIFI8iGtaj08eUz9YDr4EjQQeXrFM6RFU+7cdhdXCJg9GtM8cbeUmEV4lC6I0kRyoyKn7U4hRMYAwDSc25dTK0YCiZZ9cIq5l6hqHUj/ATXAqWFwYJR6sYB14E2xb8NAA1QEg9Fje4j+Bch93nnVS0HuwqegBfHjoJ7Qm08VO3A08TnHkyVLE+rlLdT6TZSoUO6pUCMBWHn8m5/EnjynATOP/KnmuGX1XHVjy9XPFt0f+VCwHNaf7QGQ7GyScgT2peVk32W7pKdJ6A1kZS4zppeLcCs7WiKCYbHGP8DYK0hhXRUqdIXS2U9suoE0f/Jqx1abMQX9DMjDNmkrsKbtDn84kZRsqTGeGRPn2+TvP7fXw2YP2pvuWBiagtx/hIi609tsepBSV1340R0fja8U6X6LouHtrST/CxNoJQu1nWLjOYMyu3pCTflfmyUAOi2Haz0V6ECaArjEmw24zc9Qt2SBlQG1e8w/OfnoIMak5WGoPVxykVpPlOCD+yiMKC8JYhS5weLBha4mczYKQ2B6Fv+MZH9mklmqUN4IUdNrdgiQyQDHVSTexXjITZqiOXHP8N+H9yOM4hghr9BFuQG3eU5q7bHfLkBOzZIZnIWFH2zcmr6V3/z0FOQzfD/zlOQKryMhOhllbBIQLfPh+AUfVpHDnknw= 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: Oscar and I have been exchanging a bit of email recently about the bug reported here: https://lore.kernel.org/all/ZXNhGsX32y19a2Xv@casper.infradead.org I've come to the conclusion that folio_test_hugetlb() is just too fragile as it can give both false positives and false negatives, as well as resulting in the above bug. With this patch series, it becomes a lot more robust. In the memory-failure case, we always hold the hugetlb_lock so it's perfectly reliable. In the compaction caase, it's unreliable, but the failures are acceptable and we recheck after taking the hugetlb_lock. The cost of this reliability is that we now consume the word I recently freed in folio->page[1]. I think this is acceptable; we've still gained a completely reliable folio_test_hugetlb() (which we didn't have before I started messing around with the folio dtors). Non-hugetlb users can use large_id as a pointer to something else entirely, or even as a non-pointer, as long as they can guarantee it can't conflict (ie don't use it as a bitfield). So far, this is working for me. Some stress testing would be appreciated. Matthew Wilcox (Oracle) (5): hugetlb: Make folio_test_hugetlb safer to call hugetlb: Add hugetlb_pfn_folio memory-failure: Use hugetlb_pfn_folio memory-failure: Reorganise get_huge_page_for_hwpoison() compaction: Use hugetlb_pfn_folio in isolate_migratepages_block include/linux/hugetlb.h | 13 ++----- include/linux/mm.h | 8 ----- include/linux/mm_types.h | 4 ++- include/linux/page-flags.h | 25 +++---------- kernel/vmcore_info.c | 3 +- mm/compaction.c | 16 ++++----- mm/huge_memory.c | 10 ++---- mm/hugetlb.c | 72 +++++++++++++++++++++++++++++--------- mm/memory-failure.c | 14 +++++--- 9 files changed, 87 insertions(+), 78 deletions(-)