Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1058916ybt; Wed, 8 Jul 2020 19:56:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzlo/gzz3rGy7Oz6Pg29r+fUXAA/R7nfcqhSjWHO6iNuDvXabs7uUgmXOTWfXwHqoh7jEpU X-Received: by 2002:aa7:dc46:: with SMTP id g6mr65190250edu.194.1594263404345; Wed, 08 Jul 2020 19:56:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594263404; cv=none; d=google.com; s=arc-20160816; b=U8UK1S4AgUhTsngx/KdROn7w41VrXEdC1Tmg/56XWX8gEKWTEJRnZ/B+OurwsYmjoD gMtqBFhTNFzO6zwr84ay6mGgce1lOCnTC9j7kMKRPrQuYM+6YLPZGkFofMCwBYi+3q50 0p1KY6tyZsIY39zH7s4QF8WbqTBP9rfGZbl4pWZhH6JKhJaJUW+xJgyTq0849Ofo5ChP +GphOT1D7BdiKytFp9KXeEEDW3ESBv5CIL4DF2TU4II4OVtWQXQe3FqwNh4VYCjYUxB7 egAwcYmriX2IiiGuj/X8KK6j9N8vqiT8Z94/+OU8oOWhER4785/ugismuTr9xIYAYbYp GIzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature; bh=nye4NdaG5dAL78cCI4CJpd47oNr+iAeAZv6dSMBcMdY=; b=Afyl8GiWduhxJBld6ZSqCbX7IKDx6YIhqDKVzs+dMcBZ+Qv3DMWAL/BoHnNrJU9ShR F529RD5E019mXourSW9c8XKLf8sskpnQLQ0WE2vceSpf6/y88gaNPC0keZVgOY+4HBxl DUJvRyNn3IVbrCmXNjeZ82G4KFip8N68JwJTZWoePLs3iTv85Uc2nXLM/MngIyTo85tN ob7hTNz/nXYcfmOuZ2G1s92lFMQ6PzlC/nBRz6gCFglFd5Ie+eMQWaw9ifrFRP9mJ2fR p92MkdmU1yo/KfMJGDvzRvYGkZ7iK8hUvUxYwonPG0gx88MgLM3WFWHGdSKUaHPd3jlm wsjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@synology.com header.s=123 header.b=ZLuZ8aCT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=synology.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n7si1059314ejk.154.2020.07.08.19.56.08; Wed, 08 Jul 2020 19:56:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@synology.com header.s=123 header.b=ZLuZ8aCT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=synology.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726185AbgGICz1 (ORCPT + 99 others); Wed, 8 Jul 2020 22:55:27 -0400 Received: from mail.synology.com ([211.23.38.101]:55132 "EHLO synology.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726117AbgGICz0 (ORCPT ); Wed, 8 Jul 2020 22:55:26 -0400 X-Greylist: delayed 425 seconds by postgrey-1.27 at vger.kernel.org; Wed, 08 Jul 2020 22:55:26 EDT Received: from localhost.localdomain (unknown [10.17.32.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by synology.com (Postfix) with ESMTPSA id 652BACE78121; Thu, 9 Jul 2020 10:48:20 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synology.com; s=123; t=1594262900; bh=joCChp/WKfH+meqYEh6O1+n19ugnHJTEgLQjLh1PDfc=; h=From:To:Cc:Subject:Date; b=ZLuZ8aCT+6gGFY+ohMiEojJ4oOV2pBw2sne/+6IJlx0EL4ZmJHpU/xKVOgKCV3xCD iuYYZqB7D2QpybkJmhU/zjgVvroAWAdjJ6dP6jPd9FlEMXDQEAwCSVuh2YH5bYFGGS vS2c4ageUbB6vN5dJg3a169n7maNQL06LE06niYo= From: robbieko To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Robbie Ko Subject: [PATCH] mm : fix pte _PAGE_DIRTY bit when fallback migrate page Date: Thu, 9 Jul 2020 10:48:08 +0800 Message-Id: <20200709024808.18466-1-robbieko@synology.com> X-Mailer: git-send-email 2.17.1 X-Synology-MCP-Status: no X-Synology-Spam-Flag: no X-Synology-Spam-Status: score=0, required 6, WHITELIST_FROM_ADDRESS 0 X-Synology-Virus-Status: no Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Robbie Ko When a migrate page occurs, we first create a migration entry to replace the original pte, and then go to fallback_migrate_page to execute a writeout if the migratepage is not supported. In the writeout, we will clear the dirty bit of the page and use page_mkclean to clear the dirty bit along with the corresponding pte, but page_mkclean does not support migration entry. The page ditry bit is cleared, but the dirty bit of the pte still exists, so if mmap continues to write, it will result in data loss. We fix the by first remove the migration entry and then clearing the dirty bits of the page, which also clears the pte's dirty bits. Signed-off-by: Robbie Ko --- mm/migrate.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/migrate.c b/mm/migrate.c index f37729673558..5c407434b9ba 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -875,10 +875,6 @@ static int writeout(struct address_space *mapping, struct page *page) /* No write method for the address space */ return -EINVAL; - if (!clear_page_dirty_for_io(page)) - /* Someone else already triggered a write */ - return -EAGAIN; - /* * A dirty page may imply that the underlying filesystem has * the page on some queue. So the page must be clean for @@ -889,6 +885,10 @@ static int writeout(struct address_space *mapping, struct page *page) */ remove_migration_ptes(page, page, false); + if (!clear_page_dirty_for_io(page)) + /* Someone else already triggered a write */ + return -EAGAIN; + rc = mapping->a_ops->writepage(page, &wbc); if (rc != AOP_WRITEPAGE_ACTIVATE) -- 2.17.1