linux-kernel - Re: [PATCH] mm/migrate: fix race between lock page and clear PG

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

Message-Id: <20220314212127.a2797926ee0ef8a7ad05dcaa@linux-foundation.org>
Date:   Mon, 14 Mar 2022 21:21:27 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Andrew Yang <andrew.yang@...iatek.com>
Cc:     Matthias Brugger <matthias.bgg@...il.com>,
        Matthew Wilcox <willy@...radead.org>,
        "Vlastimil Babka" <vbabka@...e.cz>,
        David Howells <dhowells@...hat.com>,
        "William Kucharski" <william.kucharski@...cle.com>,
        David Hildenbrand <david@...hat.com>,
        Yang Shi <shy828301@...il.com>, Marc Zyngier <maz@...nel.org>,
        <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-mediatek@...ts.infradead.org>, <wsd_upstream@...iatek.com>,
        Nicholas Tang <nicholas.tang@...iatek.com>,
        Kuan-Ying Lee <Kuan-Ying.Lee@...iatek.com>
Subject: Re: [PATCH] mm/migrate: fix race between lock page and clear
 PG_Isolated

On Tue, 15 Mar 2022 11:05:15 +0800 Andrew Yang <andrew.yang@...iatek.com> wrote:

> When memory is tight, system may start to compact memory for large
> continuous memory demands. If one process tries to lock a memory page
> that is being locked and isolated for compaction, it may wait a long time
> or even forever. This is because compaction will perform non-atomic
> PG_Isolated clear while holding page lock, this may overwrite PG_waiters
> set by the process that can't obtain the page lock and add itself to the
> waiting queue to wait for the lock to be unlocked.
> 
> CPU1                            CPU2
> lock_page(page); (successful)
>                                 lock_page(); (failed)
> __ClearPageIsolated(page);      SetPageWaiters(page) (may be overwritten)
> unlock_page(page);
> 
> The solution is to not perform non-atomic operation on page flags while
> holding page lock.

Sure, the non-atomic bitop optimization is really risky and I suspect
we reach for it too often.  Or at least without really clearly
demonstrating that it is safe, and documenting our assumptions.

I'm thinking this one should be backported, so I'll queue it for
5.18-rc1, with a cc:stable so it gets trickled back.