linux-kernel - Re: [PATCH v1] mm/vmscan: Account hwpoisoned folios in reclaim statistics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e2b183cd-dfd7-4eb2-b454-8966e695a9b4@163.com>
Date: Fri, 4 Jul 2025 11:14:13 +0800
From: wangxuewen <18810879172@....com>
To: David Hildenbrand <david@...hat.com>, akpm@...ux-foundation.org
Cc: zhengqi.arch@...edance.com, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, wangxuewen <wangxuewen@...inos.cn>
Subject: Re: [PATCH v1] mm/vmscan: Account hwpoisoned folios in reclaim
 statistics

> Hi David,
>  
> Thank you for your insightful feedback. You make an excellent point - 
> hwpoisoned pages are indeed not truly "reclaimed" as they don't contribute 
> to available memory but represent permanently lost capacity.
>  
> I will drop this patch.
>  
> Best regards,
> wangxuewen



在 2025/7/2 17:44, David Hildenbrand 写道:
> On 02.07.25 11:34, 18810879172@....com wrote:
>> From: wangxuewen <wangxuewen@...inos.cn>
>>
>> When encountering a hardware-poisoned folio in shrink_folio_list(),
>> we unmap and release the folio but fail to account it in the reclaim
>> statistics (sc->nr_reclaimed). This leads to an undercount of
>> actually reclaimed pages, potentially causing unnecessary additional
>> reclaim pressure.
> 
> I'll just note that this kind-of makes sense: the memory is not actually 
> reclaimed -- we don't get free memory back. The hwpoisoned page is lost.
>