linux-kernel - Re: v5.18-rc1: migratepages triggers VM_BUG_ON_FOLIO(folio_nr_pages(old) != nr

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]

Date:   Mon, 4 Apr 2022 17:06:21 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Zi Yan <ziy@...dia.com>
Cc:     Naoya Horiguchi <naoya.horiguchi@...ux.dev>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...nel.org>,
        Naoya Horiguchi <naoya.horiguchi@....com>
Subject: Re: v5.18-rc1: migratepages triggers
 VM_BUG_ON_FOLIO(folio_nr_pages(old) != nr_pages)

On Mon, Apr 04, 2022 at 11:44:39AM -0400, Zi Yan wrote:
> I am wondering if my change is the right fix or not. folios with order>0
> are still available when CONFIG_TRANSPARENT_HUGEPAGE is not set, right?

That's the eventual plan, but it's not possible today.  We need to
be able to split large folios (eg in truncation) and that functionality
is still under CONFIG_TRANSPARENT_HUGEPAGE in mm/huge_memory.c.  So
large folios depend on CONFIG_TRANSPARENT_HUGEPAGE instead of having a
clean separation between functionality-to-support-PMD-mapping and
functionality-to-support-order>0.

So I preferred your earlier patch because it's more obvious.  I mean,
we could pull in the two or three patches from my tree that convert
these functions and their callers to folios ... we're only at rc1.
I can post them and see what others think.