From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E8B7C2288E3 for ; Wed, 14 Jan 2026 14:48:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768402113; cv=none; b=MiNugl/z94fBGLMjuFn2mvvirI6m0eOsv9hwQDJrWGWpU3ON9NjxHxzgz2OFtCwkk7CVpGwQKaGQ3FaZ2PsBY14b/FAIXZ6xf9c+ZqIOYdf+GHp6nFWpLp5EZ4rl3Ys28N2b2+rboY3MB0GA6mZidzr4oh7QcrV2vFJboQseR/w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768402113; c=relaxed/simple; bh=3kBla3LH5Ux44ufJ5XiavvLxJdqOhTh8RjpmvtIPTDE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=UoCpbwrM2dfwYCXElQIxIdeVGEi7HPIqr0gHgxbXgFq37Fk742rPvkilpZY/2YWAg05FYB7vpOM/P3fhqocyxHm2mcP760KkMr/TLsEoZYYJEp0en7A7PtJ0tYfMvib8o1wEoTpNWQS/Z7Zr5V/WP89Nq2ZsVkdQ0Ra7cnVpE40= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=delta-utec.com; spf=none smtp.mailfrom=delta-utec.com; dkim=pass (2048-bit key) header.d=delta-utec-com.20230601.gappssmtp.com header.i=@delta-utec-com.20230601.gappssmtp.com header.b=QjwK7ejv; arc=none smtp.client-ip=209.85.218.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=delta-utec.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=delta-utec.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=delta-utec-com.20230601.gappssmtp.com header.i=@delta-utec-com.20230601.gappssmtp.com header.b="QjwK7ejv" Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-b8765b80a52so129723766b.2 for ; Wed, 14 Jan 2026 06:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delta-utec-com.20230601.gappssmtp.com; s=20230601; t=1768402110; x=1769006910; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Eti2jnWjJ/3cvre+2VBJiNqFzyCXhnTtCeagxJqKsCQ=; b=QjwK7ejvqiJL9B30158kJIu5nJtCfaN6pyKc2K6izclg4aPLgBx5C0Aqf3WhZ5JeqY iD5GqEGdcsZNx6YDtqQhfq/k0eobuJv5RjYcicSwGUIAbJ68C9lhd3MzbYFTUFvviTh7 W/18oCnyPYQi3I6BnSY9EPRnLyPJbSe/klZrLgOOjlMX+ot2MntNbqTwKgDD08yP5wJh NBkYKl4PpThfI5LOUmXGtqPIVs/ZBIszd45s4kYBW5vQDLtbrcUsxwedpFb2H4I0c7ET C9pDmXThhbe0HTLyNH4GK1lMH1R3AN3uFBGIcs2DEcg1RMCAozHBJwlgDhOuDI8asrjw wDOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768402110; x=1769006910; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Eti2jnWjJ/3cvre+2VBJiNqFzyCXhnTtCeagxJqKsCQ=; b=XfESu8gyO35NPBsd3ow8n7PPlkIiCdfrzk7dH5Boi/cMNROjKFQ4psbHp16WpU/9Dv 39c48vQsRCZWEWjY1CS9aTW5bqWfzCPySW1oHWrMi30TZrBjjtY2RaOiSwqgfNLCg/58 iaAIuuVyJXX7n4EDqzDEQ8fW7+MhanUOJyqpMQjqIGJD3lc4C4/vUMwEXiHhNq3Oe1mv 2kOQnZKJoGHPv2lpVz4yISXCgcQXejN0pWzwAEuHouKnxBflIUjfS2lT+tJWJQavwMNa 7/nxjqnJPD8PwnHSX4YlfTYE5etT8d3qbwuQGxDw39kH9LmST2+sGwLfyjPyKfPWuQAj JErg== X-Forwarded-Encrypted: i=1; AJvYcCVzI3WFvfmF0Ku9lBiISyT/tRESm7VB/POdk3Xp8AN12B1vowtogFLS/kajCX0+F+i/LjqgBYpMvWgpJA0=@vger.kernel.org X-Gm-Message-State: AOJu0Yxn6XyRq/NQOf26WlBWKZBsHUjPy99S1VkgS8BevENdHs/P/sNx nKuTmfbnO5Zzm7RQTpQF7AKLk0YvLdepiLsgNDm+aaghZaxQxtnh90+11ZtUW+hT2A== X-Gm-Gg: AY/fxX4NkOmudrfzBHS6OeaenqEQ8QIfk3Tqz/YoeC3AniUS57I7mqv9BkILNlwpC8L TrJx0ipTsNyuzSJFzgmi8qFKHG0tct7yuHT6haHJEtsgOIuZV4vMpMNoQCxh6YfTCgFcbFbEZNV pYD57z/pVbNU4GFK14+Nh5di0mC6QwTic7HpI4V7A26QO4sr3Mu7XZPElWMRYM28NCEhNzmMf8W f/PYTW6XaeFbM+zxf0carxJQx/QvzGcV7ZrDCB7OZ3NUSJEN16NcPw0bXZQnmgKWFhUw5PU5j/4 0HBFJ2aOlWCiLGbuNHMbrXKlf5lDs3zJ6i9F4SNp/Ymv/fHt9uUfrt5U0mIVJje9tLuHbbN9id0 Zem+LWI8UNOkCzrJKOGXkLu8f5AuJmHoHDAPDdU5rtsiH2WAUxlBjPmImeSXGvlSoJlQxrbj1RJ r95HXyXKaiFNaIImVPjs1qn1tQgYLYYVpitEjQXOo00HG+7RpzVxfmwTAFlZztPq0EMtJfCJ0A6 JK1tZsC+LzwuIkzhvmugYY5vYYSkAqBP7Un+6hR++GbBGBV6Kw= X-Received: by 2002:a17:907:6e86:b0:b80:42cf:1157 with SMTP id a640c23a62f3a-b87677a81aemr176504766b.36.1768402109968; Wed, 14 Jan 2026 06:48:29 -0800 (PST) Received: from localhost.localdomain (2001-1c00-3405-d100-3dcf-422a-3166-cbb7.cable.dynamic.v6.ziggo.nl. [2001:1c00:3405:d100:3dcf:422a:3166:cbb7]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8715952fc3sm962438766b.50.2026.01.14.06.48.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jan 2026 06:48:29 -0800 (PST) From: Boudewijn van der Heide To: ziy@nvidia.com Cc: akpm@linux-foundation.org, boudewijn@delta-utec.com, hannes@cmpxchg.org, jackmanb@google.com, linmiaohe@huawei.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.com, nao.horiguchi@gmail.com, osalvador@suse.de, surenb@google.com, vbabka@suse.cz Subject: Re: [PATCH] mm/page_alloc: Fix freeing of failed-split poisoned compound pages Date: Wed, 14 Jan 2026 15:48:23 +0100 Message-ID: <20260114144824.69960-1-boudewijn@delta-utec.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <54CB622C-0BB0-4772-A939-162D63433A00@nvidia.com> References: <54CB622C-0BB0-4772-A939-162D63433A00@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit > > free_pages_prepare() only handles poisoned order-0 pages. > > In memory_failure() (hard offline), pages > > are poisoned before attempting to split huge pages. If the split fails, > > the page remains a compound (order > 0) but is already poisoned. However, > > Soft-offline pages are always poisoned as order-0 after migration, so > > they are unaffected. > > > > The '!order' check causes these poisoned compound pages to skip > > poison handling, leaving them in the buddy allocator. > > > > Worst case, a poisoned compound page could be reallocated, > > potentially leading to crashes, silent data corruption, > > or unwanted memory containment actions before the poison bit is detected. > > > > This patch removes the '&& !order' restriction. Cleanup functions in the > > poison-handling block correctly handle non-zero order pages, making > > this change safe. > This is not a fix. IIUC, for >0 order free pages, memory failure uses > take_page_off_buddy() in a different code path. > Thanks again for the quick response and clarification! >From my understanding, you correctly noted that take_page_off_buddy() handles already-free pages, removing them from the buddy lists and setting SetPageHWPoisonTakenOff(). This prevents those pages from re-entering the buddy allocator. My concern is about in-use THP-backed compound pages: 1. A compound page is in use. 2. memory_failure() marks it poisoned (TestSetPageHWPoison). 3. try_to_split_thp_page() fails. 4. The process using the THP may be killed; the page remains compound and poisoned. 5. Later, when the page is finally freed, it reaches free_pages_prepare(); 'take_page_off_buddy()' is not invoked in this path. At this point, the current check: 'if (unlikely(PageHWPoison(page)) && !order)' will not trigger, because the order > 0. > Miaohe (cc’d) should be able to elaborate more on it. Thanks for Cc'ing Miaohe, hopefully Miaohe can provide some more insights! Thanks, Boudewijn