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 774F6C433F5 for ; Mon, 21 Mar 2022 23:26:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C006E6B0072; Mon, 21 Mar 2022 19:26:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B86946B0073; Mon, 21 Mar 2022 19:26:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A00AF6B0074; Mon, 21 Mar 2022 19:26:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 8FAA96B0072 for ; Mon, 21 Mar 2022 19:26:18 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 70E6B61533 for ; Mon, 21 Mar 2022 23:26:18 +0000 (UTC) X-FDA: 79269979236.06.AC554FE Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf09.hostedemail.com (Postfix) with ESMTP id B702C14000D for ; Mon, 21 Mar 2022 23:26:17 +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 2CDBAB817FB; Mon, 21 Mar 2022 23:26:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 727CDC340E8; Mon, 21 Mar 2022 23:26:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1647905175; bh=zm2PRxe5xFsuwQYNcENkfpKJjH4eQjyHej02f6w7vjg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fGhw3WkLFHitotKvT3JlzZG0riB2q+AE/MkryHbgTQjYGLXL1C233leDbR81IFofB NsHl5gPddbUrnzYwKJ7L5eLUUCYrCoFtWd8VdcspYc3DsurGS3obuw3Itzlr/3UxFF ypV18Zu9I53mSAM9ws3iNQX4xxY19wBQRcw++xqQ= Date: Mon, 21 Mar 2022 16:26:13 -0700 From: Andrew Morton To: Matthew Wilcox Cc: Andrew Yang , Matthias Brugger , Vlastimil Babka , David Howells , William Kucharski , David Hildenbrand , Yang Shi , Marc Zyngier , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, wsd_upstream@mediatek.com, Nicholas Tang , Kuan-Ying Lee Subject: Re: [PATCH] mm/migrate: fix race between lock page and clear PG_Isolated Message-Id: <20220321162613.0a3510d18f1fa0f1637e9661@linux-foundation.org> In-Reply-To: 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 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=fGhw3WkL; spf=pass (imf09.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: rspam02 X-Rspamd-Queue-Id: B702C14000D X-Stat-Signature: 3rrrfm1hwygq5uotebbcm9mgp9jksasn X-HE-Tag: 1647905177-515552 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 03:32:16 +0000 Matthew Wilcox wrote: > On Tue, Mar 15, 2022 at 11:05:15AM +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. > > > > Signed-off-by: andrew.yang > > --- > > include/linux/page-flags.h | 2 +- > > mm/migrate.c | 12 ++++++------ > > 2 files changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h > > index 1c3b6e5c8bfd..64a84a9835cb 100644 > > --- a/include/linux/page-flags.h > > +++ b/include/linux/page-flags.h > > @@ -918,7 +918,7 @@ PAGE_TYPE_OPS(Guard, guard) > > > > extern bool is_free_buddy_page(struct page *page); > > > > -__PAGEFLAG(Isolated, isolated, PF_ANY); > > +PAGEFLAG(Isolated, isolated, PF_ANY); > > Agreed. Further, page cannot be a tail page (this is implied by the > get_page_unless_zero() as tailpages have a zero refcount, and it > is assumed by __PageMovable() as page->mapping is undefined for tail > pages). So this can actually be: > > +PAGEFLAG(Isolated, isolated, PF_NO_TAIL); > > I considered PF_ONLY_HEAD, but there are a lot more places that _check_ > PageIsolated() and I don't want to prove that they're all definitely > working on head pages. There was no followup to this. I'll send the patch upstream as-is, but please let's not forget this idea.