From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD442C433EF for ; Tue, 15 Mar 2022 04:21:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4102D8D0003; Tue, 15 Mar 2022 00:21:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3BFDD8D0001; Tue, 15 Mar 2022 00:21:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 287038D0003; Tue, 15 Mar 2022 00:21:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0109.hostedemail.com [216.40.44.109]) by kanga.kvack.org (Postfix) with ESMTP id 195D18D0001 for ; Tue, 15 Mar 2022 00:21:32 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C1446181CE2A2 for ; Tue, 15 Mar 2022 04:21:31 +0000 (UTC) X-FDA: 79245321582.24.CBF4C7F Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf01.hostedemail.com (Postfix) with ESMTP id 3781D40007 for ; Tue, 15 Mar 2022 04:21:31 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id CF877B80FAC; Tue, 15 Mar 2022 04:21:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4DFCC340E8; Tue, 15 Mar 2022 04:21:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1647318088; bh=92N7wiO5DH6MIG7OI/keYmonozvVE63Ota9hoIR7/bo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=a3nmDbj9hIT5BHXOrUkOgHJYejfbiyt36AMauCj+660L/ij+0r8qn3+t7ZeUru05p WmdLq6/EgFi+wTmQStXFtofJdKqaaEwD4lQAg9BIftk1nxnhH5IwKLeX47t6SzeBmJ moVvwt94fdpD5H2p6mEK36/n8WHJ+mkJBLKt07w8= Date: Mon, 14 Mar 2022 21:21:27 -0700 From: Andrew Morton To: Andrew Yang Cc: Matthias Brugger , Matthew Wilcox , "Vlastimil Babka" , David Howells , "William Kucharski" , David Hildenbrand , Yang Shi , Marc Zyngier , , , , , , Nicholas Tang , Kuan-Ying Lee Subject: Re: [PATCH] mm/migrate: fix race between lock page and clear PG_Isolated Message-Id: <20220314212127.a2797926ee0ef8a7ad05dcaa@linux-foundation.org> In-Reply-To: <20220315030515.20263-1-andrew.yang@mediatek.com> References: <20220315030515.20263-1-andrew.yang@mediatek.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: bfeeoiy3muxm1t4qgmdpr3mku8mjx41k Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=a3nmDbj9; spf=pass (imf01.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 3781D40007 X-HE-Tag: 1647318091-528114 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 15 Mar 2022 11:05:15 +0800 Andrew Yang 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.