linux-kernel - Re: [PATCH v9 2/8] mm/huge_memory: add two new (not yet used) functions for folio

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: <fd0ca9d8-e8b2-dc2d-d2c7-030a49a13035@google.com>
Date: Wed, 5 Mar 2025 13:49:13 -0800 (PST)
From: Hugh Dickins <hughd@...gle.com>
To: Zi Yan <ziy@...dia.com>
cc: Hugh Dickins <hughd@...gle.com>, linux-mm@...ck.org, 
    Andrew Morton <akpm@...ux-foundation.org>, 
    "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, 
    "Matthew Wilcox (Oracle)" <willy@...radead.org>, 
    Ryan Roberts <ryan.roberts@....com>, David Hildenbrand <david@...hat.com>, 
    Yang Shi <yang@...amperecomputing.com>, Miaohe Lin <linmiaohe@...wei.com>, 
    Kefeng Wang <wangkefeng.wang@...wei.com>, Yu Zhao <yuzhao@...gle.com>, 
    John Hubbard <jhubbard@...dia.com>, 
    Baolin Wang <baolin.wang@...ux.alibaba.com>, 
    linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org, 
    Kairui Song <kasong@...cent.com>, Liu Shixin <liushixin2@...wei.com>
Subject: Re: [PATCH v9 2/8] mm/huge_memory: add two new (not yet used)
 functions for folio_split()

On Wed, 5 Mar 2025, Zi Yan wrote:
> On 5 Mar 2025, at 15:50, Hugh Dickins wrote:
> >
> > (Historically, there was quite a lot of difficulty in getting the order
> > of events in __split_huge_page_tail() to be safe: I wonder whether we
> > shall see a crop of new weird bugs from these changes. I note that your
> > loops advance forwards, whereas the old ones went backwards: but I don't
> > have anything to say you're wrong.  I think it's mainly a matter of how
> > the first tail or two gets handled: which might be why you want to
> > folio_set_order(folio, new_order) at the earliest opportunity.)
> 
> I am worried about that too. In addition, in __split_huge_page_tail(),
> page refcount is restored right after new tail folio split is done,
> whereas I needed to delay them until all new after-split folios
> are done, since non-uniform split is iterative and only the after-split
> folios NOT containing the split_at page will be released. These
> folios are locked and frozen after __split_folio_to_order() like
> the original folio. Maybe because there are more such locked frozen
> folios than before?

Sorry, I gave up trying to work out what you're asking me there.
Let's assume I don't know the answer.

Hugh