linux-kernel - Re: [PATCH 0/4] mm: page_ext: Introduce new iteration API

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <fdc8fbb3-0d2f-4422-8437-078cb2ce1a9a@redhat.com>
Date: Thu, 20 Feb 2025 15:23:02 -0500
From: Luiz Capitulino <luizcap@...hat.com>
To: David Hildenbrand <david@...hat.com>,
 Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, yuzhao@...gle.com,
 pasha.tatashin@...een.com, hannes@...xchg.org, muchun.song@...ux.dev
Subject: Re: [PATCH 0/4] mm: page_ext: Introduce new iteration API

On 2025-02-20 05:49, David Hildenbrand wrote:
> On 20.02.25 00:52, Andrew Morton wrote:
>> On Tue, 18 Feb 2025 21:17:46 -0500 Luiz Capitulino <luizcap@...hat.com> wrote:
>>
>>> To fix this, this series introduces a new iteration API for page extension
>>> objects. The API checks if the next page extension object can be retrieved
>>> from the current section or if it needs to look up for it in another
>>> section.
>>>
>>> ...
>>
>> A regression since 6.12, so we should backport the fix.
>>
>>> ...
>>>
>>>   include/linux/page_ext.h | 67 +++++++++++++++++++++++++++++++++++++---
>>>   mm/page_ext.c            | 48 ++++++++++++++++++++++++++++
>>>   mm/page_owner.c          | 61 +++++++++++++++++-------------------
>>>   mm/page_table_check.c    | 39 +++++++----------------
>>>   4 files changed, 152 insertions(+), 63 deletions(-)
>>
>> That's a lot to backport!
>>
>> Is there some quick-n-dirty fixup we can apply for the sake of -stable
>> kernels, then work on this long-term approach for future kernels?
> 
> I assume we could loop in reset_page_owner()/page_table_check_free()/set_page_owner()/page_table_check_alloc(). Not-so-nice for upstream, maybe good-enough for stable. Still nasty :)

I think Andrew wants to have the quick-n-dirty fix for upstream, so that
it's easier to backport to -stable. Then we work on this solution on top.

> OTOH, we don't really expect a lot of conflicts.

Yes, I was able to apply this series on top of 6.12.15 without conflicts.
Given that -stable does backport a lot of fixes anyways, I would push for
having this on -stable.

But just to answer the original question: I can't think of quick-n-dirty,
but I can think of easy-n-ugly:

  1. We could add a check for MAX_PAGE_ORDER for the first function in a
     call chain calling page_ext_next() (that is, bail out if > MAX_PAGE_ORDER)

  2. We could replace all page_ext_next() calls to a version of look_page_ext()
     that takes a PFN

But all these ideas have regression risk as well, so I don't see the advantage.