linux-kernel - Re: [PATCH mm-unstable v2] mm/page_alloc: keep track of free highatomic

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: <6ac7a38f-30df-4403-8723-a43829bcdba5@suse.cz>
Date: Sun, 27 Oct 2024 22:05:50 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Yu Zhao <yuzhao@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Johannes Weiner <hannes@...xchg.org>, Zi Yan <ziy@...dia.com>,
 Mel Gorman <mgorman@...hsingularity.net>,
 Matt Fleming <mfleming@...udflare.com>, David Rientjes
 <rientjes@...gle.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 Link Lin <linkl@...gle.com>
Subject: Re: [PATCH mm-unstable v2] mm/page_alloc: keep track of free
 highatomic

On 10/27/24 21:51, Yu Zhao wrote:
> On Sun, Oct 27, 2024 at 2:36 PM Vlastimil Babka <vbabka@...e.cz> wrote:
>>
>> On 10/27/24 21:17, Yu Zhao wrote:
>> > On Sun, Oct 27, 2024 at 1:53 PM Vlastimil Babka <vbabka@...e.cz> wrote:
>> >>
>>
>> For example:
>>
>> - a page is on pcplist in MIGRATE_MOVABLE list
>> - we reserve its pageblock as highatomic, which does nothing to the page on
>> the pcplist
>> - page above is flushed from pcplist to zone freelist, but it remembers it
>> was MIGRATE_MOVABLE, merges with another buddy/buddies from the
>> now-highatomic list, the resulting order-X page ends up on the movable
>> freelist despite being in highatomic pageblock. The counter of free
>> highatomic is now wrong wrt the freelist reality
> 
> This is the part I don't follow: how is it wrong w.r.t. the freelist
> reality? The new nr_free_highatomic should reflect how many pages are
> exactly on free_list[MIGRATE_HIGHATOMIC], because it's updated
> accordingly.

You'd have to try implementing your change in the kernel without that
migratetype hygiene series, and see how it would either not work, or you'd
end up implementing the series as part of that.

> (My current understanding is that, in this case, the reservation
> itself is messed up, i.e., under-reserved.)
> 
>> The series has addressed various scenarios like that, where page can end up
>> on the wrong freelist.