linux-kernel - Re: [PATCH] mm, compaction: fix fast_isolate

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20221027132557.5f724149bd5753036f41512a@linux-foundation.org>
Date:   Thu, 27 Oct 2022 13:25:57 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     NARIBAYASHI Akira <a.naribayashi@...itsu.com>
Cc:     vbabka@...e.cz, mgorman@...hsingularity.net, rientjes@...gle.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH] mm, compaction: fix fast_isolate_around() to stay
 within boundaries

On Wed, 26 Oct 2022 20:24:38 +0900 NARIBAYASHI Akira <a.naribayashi@...itsu.com> wrote:

> Depending on the memory configuration, isolate_freepages_block() may
> scan pages out of the target range and causes panic.
> 
> The problem is that pfn as argument of fast_isolate_around() could
> be out of the target range. Therefore we should consider the case
> where pfn < start_pfn, and also the case where end_pfn < pfn.
> 
> This problem should have been addressd by the commit 6e2b7044c199
> ("mm, compaction: make fast_isolate_freepages() stay within zone")
> but there was an oversight.
> 
>  Case1: pfn < start_pfn
> 
>   <at memory compaction for node Y>
>   |  node X's zone  | node Y's zone
>   +-----------------+------------------------------...
>    pageblock    ^   ^     ^
>   +-----------+-----------+-----------+-----------+...
>                 ^   ^     ^
>                 ^   ^      end_pfn
>                 ^    start_pfn = cc->zone->zone_start_pfn
>                  pfn
>                 <---------> scanned range by "Scan After"
> 
>  Case2: end_pfn < pfn
> 
>   <at memory compaction for node X>
>   |  node X's zone  | node Y's zone
>   +-----------------+------------------------------...
>    pageblock  ^     ^   ^
>   +-----------+-----------+-----------+-----------+...
>               ^     ^   ^
>               ^     ^    pfn
>               ^      end_pfn
>                start_pfn
>               <---------> scanned range by "Scan Before"
> 
> It seems that there is no good reason to skip nr_isolated pages
> just after given pfn. So let perform simple scan from start to end
> instead of dividing the scan into "Before" and "After".

Under what circumstances will this panic occur?  I assume those
circumstnces are pretty rare, give that 6e2b7044c1992 was nearly two
years ago.

Did you consider the desirability of backporting this fix into earlier
kernels?