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 X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7D5FC4338F for ; Sat, 7 Aug 2021 02:03:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 39BA461163 for ; Sat, 7 Aug 2021 02:03:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 39BA461163 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C1CFF8D0002; Fri, 6 Aug 2021 22:03:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BCAE56B0071; Fri, 6 Aug 2021 22:03:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB9E08D0002; Fri, 6 Aug 2021 22:03:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0024.hostedemail.com [216.40.44.24]) by kanga.kvack.org (Postfix) with ESMTP id 928576B006C for ; Fri, 6 Aug 2021 22:03:30 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 475DF18000DC4 for ; Sat, 7 Aug 2021 02:03:30 +0000 (UTC) X-FDA: 78446637780.28.2308736 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf16.hostedemail.com (Postfix) with ESMTP id DA309F008950 for ; Sat, 7 Aug 2021 02:03:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=w9N8Ou48Y2LFVsV0kIh2BGeXdTIG63Sn+jN5i3pEhAw=; b=EkD06ErMt8LCsJv+sA6F2x0MRG GSAvw4jk71oNuw//OcjExjulPEF7NOAc08+bDZQJWORiX9WSOGPZRl5BZVspOfe55axgP+vTCJj92 SH1iX/JPxZobF97Nfpg/1LouHMGysLjk6Mt8Gw/EuE38n55bNxyKnwVtf3nC+8BZLgtX6Lws3Bpqv P3iDwTKF35sj1JHnSROYyDuHZqC7ME0RPUWHFT6gWrOIwgwYfqxbDdFBvstKJGdN/XRskxMUBkZ4t pHbYL0+e03gaOJu2a9hV0XdsryZqo9jdhaaxEBlpKD/WDfKchVk51sV489zxAKiqcxdF3l2EuRqOJ 1JOoiz1Q==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mCBfV-008mWL-Cp; Sat, 07 Aug 2021 02:02:45 +0000 Date: Sat, 7 Aug 2021 03:02:33 +0100 From: Matthew Wilcox To: Baolin Wang Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/5] mm: migrate: Move the page count validation to the proper place Message-ID: References: <1f7e1d083864fbb17a20a9c8349d2e8b427e20a3.1628174413.git.baolin.wang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: DA309F008950 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=EkD06ErM; dmarc=none; spf=none (imf16.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Stat-Signature: 3ydhiziii7xti6dire7eyofarz19eecs X-HE-Tag: 1628301809-83838 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 Fri, Aug 06, 2021 at 11:07:18AM +0800, Baolin Wang wrote: > Hi Matthew, > > > On Thu, Aug 05, 2021 at 11:05:56PM +0800, Baolin Wang wrote: > > > We've got the expected count for anonymous page or file page by > > > expected_page_refs() at the beginning of migrate_page_move_mapping(), > > > thus we should move the page count validation a little forward to > > > reduce duplicated code. > > > > Please add an explanation to the changelog for why it's safe to pull > > this out from under the i_pages lock. > > Sure. In folio_migrate_mapping(), we are sure that the migration page was > isolated from lru list and locked, so I think there are no race to get the > page count without i_pages lock. Please correct me if I missed something > else. Thanks. Unless the page has been removed from i_pages, this isn't a correct explanation. Even if it has been removed from i_pages, unless an RCU grace period has passed, another CPU may still be able to inc the refcount on it (temporarily). The same is true for the page tables, by the way; if someone is using get_user_pages_fast(), they may still be able to see the page.