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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11654C433F5 for ; Mon, 21 Mar 2022 23:27:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232919AbiCUX3N (ORCPT ); Mon, 21 Mar 2022 19:29:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233120AbiCUX3F (ORCPT ); Mon, 21 Mar 2022 19:29:05 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 977F62C77BF for ; Mon, 21 Mar 2022 16:26:17 -0700 (PDT) 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 3F29FB81ABE for ; 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1C567C433F5 for ; Mon, 21 Mar 2022 23:26:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Mime-Version:References:In-Reply-To: Message-Id:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=brFPAz+0FKhSexzsU5Naru6T385rMC5LaoSYIJwBLz4=; b=3u8FfiGI6Z6Xz9 fnVouIl48Mh/fm2RVLYfG/HfBr+wXixADBth2Ngp7S0Wnq9fFDFTS/qgOM+vtSGZd5QD+kAEjh4NM N5Fvwk/fFLUjIpIU+fVqCoKKwLS5tr9+ufU6aA5/9yxEaM0Zfh6aoGEfJuOK+FSDa7OksDMTpH0HH tYQfEvisFCyewpp4J2iSc+2Q+P774puA2rU8xp43QbqjAt9tgyGRmo8EtT62oYvedbMeTEVqLK0Ch ku5AosCAASjC7dgTx0QgUvGETlaJqQVJUPAyPAM4ScobznnMHqzWBVJvknlVLGL6ToSBFu+r0y6vN BqXwpYxUPFEWRg37Efdw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWRQ0-009Og8-C9; Mon, 21 Mar 2022 23:26:32 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWRPl-009Obj-GH; Mon, 21 Mar 2022 23:26:21 +0000 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220321_162617_879536_F6E8D804 X-CRM114-Status: GOOD ( 25.17 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org 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. _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 82059C433F5 for ; Mon, 21 Mar 2022 23:27:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Mime-Version:References:In-Reply-To: Message-Id:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tH5xOTUJuSA8vkpdCiqkMWwSsA+3xdn0T1VMFAPuq5U=; b=XuJsovds335R1i W/W4m7A2JrgQmd4fLlZ9P5UAOuuqnhRcK6nEaA/oxloSzSxFthhnDgHIs4b1r51Us0L3NT5wQqIE9 +SWMMd1a+Yc4VaXNVR0ILKUAYzLaomnXl2DSKjELXf8QmRGxeukHJi+RKoIdPy3cgSjHvSSL+tbeV hTip8n8j3X4KumwviBG1OwvZ72hEVTbxioDy76T9ldFuZ/KGLexfUxrl6XQVkfjdWGzcVxGdPT3Bq XASPPzxuWE/UuuGEMecfbY7p+4f8v2Ydj9MG019xS+AR/xsIkijkC9Wiyy9es7I8T7mtD9Sl2fzCR sObibFcqzCvAzgzNrjTw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWRPr-009Odu-K6; Mon, 21 Mar 2022 23:26:23 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWRPl-009Obj-GH; Mon, 21 Mar 2022 23:26:21 +0000 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220321_162617_879536_F6E8D804 X-CRM114-Status: GOOD ( 25.17 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel