From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout01.his.huawei.com (canpmsgout01.his.huawei.com [113.46.200.216]) (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 42A1A23A562 for ; Thu, 5 Feb 2026 03:21:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.216 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770261675; cv=none; b=ETtDLV351XwWHPBAjR+gXOs1M6/wms0YPazzdFF86QwFR1lJAUepz/dDD+uD82XouUVBNkbLONQFK5OxTJu69EMrPJB6MDl4cVGPUI4uYPFDZ+ixmQxwpmxY5s4KDWzH2z691mFcSCCi9opdCILQmJe/fsIdyE2de67jzE/sCbw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770261675; c=relaxed/simple; bh=6R49jZKmlwI768Fr+o3bCuNFsGCKW4BBGul0ED+SsXA=; h=Subject:To:CC:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=F038RpGjqWcbtflJ0DL1CVORsgY1mCLdcbjgXJcxCWZYaVD1k0XNAdj/u1VlT3bqefHkPBCPy+DvUNKQTw/1RlgaYBmLqNzdAq8s/jRL+fLF+OxF06Dn6luXQeh8Dw7XmBnCTCBWcqj/hSbTI6ixhAovAY2LHB4OyppSdy2wiDg= 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=s4LUiWGC; arc=none smtp.client-ip=113.46.200.216 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="s4LUiWGC" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=LyyA1PPt7lfcB8CKs4wjIz9KHF1gMnrJMFjQaE0YHQ8=; b=s4LUiWGCqQZAkW0B6mOkXEBOqMMP0TCbhQLWY/7IMJcNDgk9KFb0gC83uJb/+Cdq8eesSLyWj RQxyp6eSVPhZ08RLr/bLU56Wgoj7kL/ny3J5YlqlUF6Ennup2KtfLY0A6b9SxlYLRT8iGNiYeo1 PBZffgnj1gjijaIDWK29Pho= Received: from mail.maildlp.com (unknown [172.19.162.223]) by canpmsgout01.his.huawei.com (SkyGuard) with ESMTPS id 4f62Sb6T8Dz1T4Gw; Thu, 5 Feb 2026 11:16:47 +0800 (CST) Received: from dggemv712-chm.china.huawei.com (unknown [10.1.198.32]) by mail.maildlp.com (Postfix) with ESMTPS id 5C02A40561; Thu, 5 Feb 2026 11:21:11 +0800 (CST) Received: from kwepemq500010.china.huawei.com (7.202.194.235) by dggemv712-chm.china.huawei.com (10.1.198.32) 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 11:21:11 +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 11:21:10 +0800 Subject: Re: WARNING in memory_failure() at include/linux/huge_mm.h:635 triggered To: , Zi Yan , "David Hildenbrand (arm)" , =?UTF-8?B?5piv5Y+C5beu?= CC: , , , 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> From: Miaohe Lin Message-ID: Date: Thu, 5 Feb 2026 11:21:09 +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: <7d5754dd-8cf5-41f3-a767-271b28b1f63c@oracle.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemq500010.china.huawei.com (7.202.194.235) 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? 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. .