linux-kernel - Re: [PATCH v2] mm/memory-failure: Support disabling soft offline for HugeTLB pages

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: <4d2e8686-8810-4901-8483-9b5eb040d489@arm.com>
Date: Sun, 21 Sep 2025 17:06:31 +0530
From: Anshuman Khandual <anshuman.khandual@....com>
To: "Luck, Tony" <tony.luck@...el.com>, Jiaqi Yan <jiaqiyan@...gle.com>
Cc: David Hildenbrand <david@...hat.com>, Kyle Meyer <kyle.meyer@....com>,
 akpm@...ux-foundation.org, corbet@....net, linmiaohe@...wei.com,
 shuah@...nel.org, jane.chu@...cle.com, Liam.Howlett@...cle.com,
 bp@...en8.de, hannes@...xchg.org, jack@...e.cz, joel.granados@...nel.org,
 laoar.shao@...il.com, lorenzo.stoakes@...cle.com, mclapinski@...gle.com,
 mhocko@...e.com, nao.horiguchi@...il.com, osalvador@...e.de,
 rafael.j.wysocki@...el.com, rppt@...nel.org, russ.anderson@....com,
 shawn.fan@...el.com, surenb@...gle.com, vbabka@...e.cz,
 linux-acpi@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
 linux-mm@...ck.org
Subject: Re: [PATCH v2] mm/memory-failure: Support disabling soft offline for
 HugeTLB pages



On 18/09/25 1:24 AM, Luck, Tony wrote:
> On Wed, Sep 17, 2025 at 12:32:47PM -0700, Jiaqi Yan wrote:
>> +1. Given /proc/sys/vm/enable_soft_offline is extensible, I would
>> prefer a compact userspace API.
>>
>>> would create a new file, and the file has weird semantics such that it
>>> has no meaning when enable_soft_offline=0.
> 
> So the expand the bitmask idea from earlier in this thread?
> 
> Bit0	0 = soft offline disabled. 1 = Enabled (but see other bits)
> Bit1	0 = allow offline of 4K pages, 1 = suppress 4K offline
> Bit2	0 = allow offline of hugetlb, 1 = suppress hugetlb offline
> Bit3	0 = allow breakup of transparent huge pages to just offline 4K, 1 = suppress transparent breakup
> Bit4+	Reserved for suppressing other page types we invent in the future
> 
> Values 0 and 1 keep their original meaning.
> 
> Value 5 means: offline 4K, keep hugetlb, breakup transparent huge pages.

This disable bitmask (but when generally enabled via bit[0] = 1) method
seems much better. But I am not sure about page size being a valid page
type classification though. Just to start with, defining first two bits
in this bitmask should be good enough, which will atleast help document
and validate this new interface properly.

Bit1	0 = allow offline of hugetlb, 1 = suppress hugetlb offline
Bit2	0 = allow breakup of transparent huge pages to just offline base pages, 1 = suppress transparent breakup
Bit3+	Reserved for suppressing other page types we invent in the future