From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEDCC2D7DC6 for ; Thu, 5 Feb 2026 07:18:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770275930; cv=none; b=L2CMt3s08Noa5KCUDRdZslsklgb9GwxCIrlsdswfBP1ilV0DCIvP5vMvmQ88zHMNm1rbJjXiFFrJikbK7jWOvYcsH6q20klyH2lqZKp8mXZ9g/g7JQxbTncJT2ESXGpC9SNUr/YgkuY7w4ULP2bhM1WguzgblGnqHDk4elsBTJI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770275930; c=relaxed/simple; bh=11J82lapadxRgZR8z9iMCZy0XHle0HHps5pbIlCZt3I=; h=Subject:To:CC:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=uLqL+wlHs8E4zVwF4e+3LORTrjPhrC7MGI6zaICzpnBolYP+PE70+x2I4C9hHkz2G4AemFa/4c9vwTjSlvcyxFHPoc4SK7END5boxWrckqGRxDZ+3k0aV5PnzJt5uCgYuwAR6u6phF2nNT6TfkNJYuQ1Z2gwdteV+TVIlzE6EUU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=4EpXynxz; arc=none smtp.client-ip=113.46.200.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="4EpXynxz" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=9gE+wocAEYGAhpH+Qx7f17X+XfuZxkf0I1SRp2D88Ss=; b=4EpXynxzOMmyGsO+mz1AV4zK9QxsASNxG3WgHKFUWAKKgH7TXVu+uqq28/0gvmzW1RySs69SW W0//IlhBtx304X3nXsCZtvfswyZXNHObTWYbBOlZ4PeRgvnRnc8HZkv4hPnXSWqVwC521dEOSkg QtuNW+SLojLNNglXYbViLVs= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4f67lM5w00z12LDJ; Thu, 5 Feb 2026 15:14:55 +0800 (CST) Received: from dggemv706-chm.china.huawei.com (unknown [10.3.19.33]) by mail.maildlp.com (Postfix) with ESMTPS id 7C9554056E; Thu, 5 Feb 2026 15:18:45 +0800 (CST) Received: from kwepemq500010.china.huawei.com (7.202.194.235) by dggemv706-chm.china.huawei.com (10.3.19.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 5 Feb 2026 15:18:45 +0800 Received: from [10.173.125.37] (10.173.125.37) by kwepemq500010.china.huawei.com (7.202.194.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 5 Feb 2026 15:18:44 +0800 Subject: Re: WARNING in memory_failure() at include/linux/huge_mm.h:635 triggered To: Zi Yan , CC: "David Hildenbrand (arm)" , =?UTF-8?B?5piv5Y+C5beu?= , , , , Matthew Wilcox References: <1db245a8-f9ab-42e4-8cc6-cc7562961921@kernel.org> <48978612-6933-4897-85DD-6740B6C8570B@nvidia.com> <25CA4D90-A24E-49C6-92D2-08080EC81466@nvidia.com> <032058DC-CD8D-406A-B986-740E41C834B2@nvidia.com> <61BBEF63-20D6-4671-B7F7-F015D49B2080@nvidia.com> <1bfc9e64-2961-4d2c-a6c3-fb123f66e6cc@kernel.org> <94DAA11B-597F-4F8F-AFFF-9D7626A7C091@nvidia.com> <7d5754dd-8cf5-41f3-a767-271b28b1f63c@oracle.com> <85CB7DEA-79EE-43EE-BA9B-C2AC81F6FA02@nvidia.com> From: Miaohe Lin Message-ID: <225f0193-e27d-bad7-56ec-09cdaed64f71@huawei.com> Date: Thu, 5 Feb 2026 15:18:44 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <85CB7DEA-79EE-43EE-BA9B-C2AC81F6FA02@nvidia.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100001.china.huawei.com (7.221.188.238) To kwepemq500010.china.huawei.com (7.202.194.235) On 2026/2/5 11:53, Zi Yan wrote: > On 4 Feb 2026, at 22:21, Miaohe Lin wrote: > >> On 2026/2/5 10:00, jane.chu@oracle.com wrote: >>> >>> >>> On 2/4/2026 1:41 PM, Zi Yan wrote: >>>> On 4 Feb 2026, at 16:37, David Hildenbrand (arm) wrote: >>>> >>>>> On 2/4/26 22:08, Zi Yan wrote: >>>>>> On 4 Feb 2026, at 14:18, David Hildenbrand (arm) wrote: >>>>>> >>>>>>> On 2/4/26 18:41, Zi Yan wrote: >>>>>>>> >>>>>>>> >>>>>>>> More details: >>>>>>>> later at sg_vma_fault(), the driver just handles a page fault by supplying >>>>>>>> a subpage from a pre-allocated compound page[3]. We then get a large folio >>>>>>>> without !CONFIG_TRANSPARENT_HUGEPAGE. >>>>>>> >>>>>>> We can identify such non-folio (but compound) things by looking at PG_large_rmappable IIRC. >>>>>> >>>>>> OK, back to the issue. The patch below should fix the issue? >>>>>> >>>>>> Hi 是参差, >>>>>> >>>>>> Can you test it? >>>>>> >>>> >>>> >>>>> I think you have to test for folio_test_large() before testing folio_test_large_rmappable(). >>>> >>>> Oh, forgot that. Thanks. >>>> >>>> >>>>  From 8dda4bba9964890462eca3ef3cce57bb4fab8313 Mon Sep 17 00:00:00 2001 >>>> From: Zi Yan >>>> Date: Wed, 4 Feb 2026 16:04:19 -0500 >>>> Subject: [PATCH] mm/memory_failure: reject unsupported non-folio compound page >>>> >>>> Signed-off-by: Zi Yan >>>> --- >>>>   mm/memory-failure.c | 8 ++++++-- >>>>   1 file changed, 6 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c >>>> index 825c706ac576..137c67fda57e 100644 >>>> --- a/mm/memory-failure.c >>>> +++ b/mm/memory-failure.c >>>> @@ -2440,9 +2440,13 @@ int memory_failure(unsigned long pfn, int flags) >>>> >>>>       folio = page_folio(p); >>>> >>>> -    /* filter pages that are protected from hwpoison test by users */ >>>> +    /* >>>> +     * filter pages that are protected from hwpoison test by users >>>> +     * or unsupported non folio compound pages >>>> +     */ >>>>       folio_lock(folio); >>>> -    if (hwpoison_filter(p)) { >>>> +    if (hwpoison_filter(p) || >>>> +        (folio_test_large(folio) && !folio_test_large_rmappable(folio))) { >>> >>> Just curious, would this filter out pte-mapped THP/mTHP folios? > > No. All folios (including pre-mapped/mTHP ones) are large_rmappable. > >> >> Thanks all. >> >> memory_failure() can meet various types of folios. So in get_hwpoison_page(), >> HWPoisonHandlable() and PageHuge() are used to check whether the folio can >> be handled. But in madvise(MADV_HWPOISON) scene, MF_COUNT_INCREASED is set in >> flag, so this check is skipped and warning triggered. Might HWPoisonHandlable() >> check be always used to make sure the folio is in sane types? Something like >> below (i.e. remove the MF_COUNT_INCREASED check before calling get_hwpoison_page): >> >> diff --git a/mm/memory-failure.c b/mm/memory-failure.c >> index 825c706ac576..ba4231858a36 100644 >> --- a/mm/memory-failure.c >> +++ b/mm/memory-failure.c >> @@ -2411,31 +2411,29 @@ int memory_failure(unsigned long pfn, int flags) >> * In fact it's dangerous to directly bump up page count from 0, >> * that may make page_ref_freeze()/page_ref_unfreeze() mismatch. >> */ >> - if (!(flags & MF_COUNT_INCREASED)) { >> - res = get_hwpoison_page(p, flags); >> - if (!res) { >> - if (is_free_buddy_page(p)) { >> - if (take_page_off_buddy(p)) { >> - page_ref_inc(p); >> - res = MF_RECOVERED; >> - } else { >> - /* We lost the race, try again */ >> - if (retry) { >> - ClearPageHWPoison(p); >> - retry = false; >> - goto try_again; >> - } >> - res = MF_FAILED; >> - } >> - res = action_result(pfn, MF_MSG_BUDDY, res); >> + res = get_hwpoison_page(p, flags); >> + if (!res) { >> + if (is_free_buddy_page(p)) { >> + if (take_page_off_buddy(p)) { >> + page_ref_inc(p); >> + res = MF_RECOVERED; >> } else { >> - res = action_result(pfn, MF_MSG_KERNEL_HIGH_ORDER, MF_IGNORED); >> + /* We lost the race, try again */ >> + if (retry) { >> + ClearPageHWPoison(p); >> + retry = false; >> + goto try_again; >> + } >> + res = MF_FAILED; >> } >> - goto unlock_mutex; >> - } else if (res < 0) { >> - res = action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED); >> - goto unlock_mutex; >> + res = action_result(pfn, MF_MSG_BUDDY, res); >> + } else { >> + res = action_result(pfn, MF_MSG_KERNEL_HIGH_ORDER, MF_IGNORED); >> } >> + goto unlock_mutex; >> + } else if (res < 0) { >> + res = action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED); >> + goto unlock_mutex; >> } >> >> folio = page_folio(p); >> >> Thanks. >> . > > This makes sense to me. And it gets rid of the warning as well. > > Can you send a proper patch of this? > > Feel free to add > > Reviewed-by: Zi Yan > Tested-by: Zi Yan Sure. Thanks for all of your work. :)