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 9BAE6C00140 for ; Tue, 16 Aug 2022 01:39:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 109788D0001; Mon, 15 Aug 2022 21:39:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0914F6B0075; Mon, 15 Aug 2022 21:39:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E4D628D0001; Mon, 15 Aug 2022 21:39:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CFF6B6B0073 for ; Mon, 15 Aug 2022 21:39:43 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AA585C038E for ; Tue, 16 Aug 2022 01:39:43 +0000 (UTC) X-FDA: 79803749046.30.1F72F86 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf24.hostedemail.com (Postfix) with ESMTP id 534AD180040 for ; Tue, 16 Aug 2022 01:39:43 +0000 (UTC) Received: by mail-pf1-f178.google.com with SMTP id u133so8089149pfc.10 for ; Mon, 15 Aug 2022 18:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=cMuUlWGLbTpeu0ASefFqDvJ/DGPqzdWcKWwAAva0H64=; b=WES+YnOZL2UjR4oBSqpkDqfy5lRMZ4Az94YlDnft7E80VXwd3QCegkIe80Y2DNmcRu exMTJsFtVAt7oqKqCDVqVwlCuuKBVkIi/cznTfu59wBPo3bUh+mt2ula0EENnUqsWqCP iOIr04Hn9JP5mUCDF8IoTZojIj/oDjxMK6VBkX9wIpu1QCZm+3dMUBq2i5bhU/b+GWpc fKkAQRnQTgBtX10tQEFcopknGrRl6Y3X9aCYwO+Qcl5QvrorZL0Y7lJYg1PKa6LW/1z9 pUhY+SX0gBQfjKk1jPI872E/x+guVVCnqOr3UsXNtruec/1Ypi6z/bPM+Vl0jbpQIcvx ONDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=cMuUlWGLbTpeu0ASefFqDvJ/DGPqzdWcKWwAAva0H64=; b=uULdExLJklWEE98MWMMu2jCNVN434+P0MuZk4MnzddNxcIfbTWxU/bhObo/iPsNLmm 1iW3VuCDtpwAqWEkqWSMK94gqjBG/js19SD1s0TP53sqMTqTo52ephkiUu0lzy+6WFLZ 5NI6qDequ11YKS5K0JGPO9X5LwKyWm2deGsJTb3XYC++8IBGwxLZQ8VVBtaf554yJNU6 6fGrt1/xx3XaLNHAwyS611GmK661AAhNZ4qUFf+T8drO12l34w70A2eo6Eh/jC2CR1VG ZPktoyp+iVgDDe4VEoCAxJBtn5AIoXCYK2OLpWsqHrdXWGCF7PYEMxT4ti/wm4qGxTid drPw== X-Gm-Message-State: ACgBeo0udzbMzTPpae+7EpfHpsdZnufa8AlqVstlkKxZOF0RZhW53ZW0 CV3npjXXXtBMWudNXOXnYvDrowIdp3QiVTqhRM4= X-Google-Smtp-Source: AA6agR7vbJv28trrDODg84BXP6+k2lJrU93pgFx3KueJKbD/mjt0HBUM90nH7LBOqgipIESu50GfUTNZc1xxADv0pQM= X-Received: by 2002:a65:5b03:0:b0:41d:131c:4f39 with SMTP id y3-20020a655b03000000b0041d131c4f39mr15846558pgq.401.1660613982246; Mon, 15 Aug 2022 18:39:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: huang ying Date: Tue, 16 Aug 2022 09:39:24 +0800 Message-ID: Subject: Re: [PATCH 1/2] mm/migrate_device.c: Copy pte dirty bit to page To: Alistair Popple Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, "Sierra Guiza, Alejandro (Alex)" , Felix Kuehling , Jason Gunthorpe , John Hubbard , David Hildenbrand , Ralph Campbell , Matthew Wilcox , Karol Herbst , Lyude Paul , Ben Skeggs , Logan Gunthorpe , linuxram@us.ibm.com, paulus@ozlabs.org, Peter Xu Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660613983; a=rsa-sha256; cv=none; b=rbElQBZmuc0OzMboNh5uJ6FTaXRyrCUkixHLcsRfLLUsabfyua32yeHQZ6mB6zyiLt8Zjb V8Bt4nHfzzIOGCr+PXWiVtTdD1mGvV8t85xmbVgFdjsmwURG5AQoX0x5IsIJTIkUO7YQlA dpLLBlzXKUMFCBn1+edfQ+owtA1thS0= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WES+YnOZ; spf=pass (imf24.hostedemail.com: domain of huang.ying.caritas@gmail.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=huang.ying.caritas@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660613983; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cMuUlWGLbTpeu0ASefFqDvJ/DGPqzdWcKWwAAva0H64=; b=5PBjZ8iR5pduOTaf4Go8yg1MiWdfb5IkDcPt0aQU3rIvSUbcwjt5z4omXHErmzx/pRCTQ+ PX93r5u0Obvy7gBGQ2iscMgl3cozGf8qizKP0SZ+VFVus5LQ+9NgosIturUAxcTcOFxyBN Iryro/Z/mUPN/G/xpMYhtuOomq89m9M= X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 534AD180040 X-Rspam-User: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WES+YnOZ; spf=pass (imf24.hostedemail.com: domain of huang.ying.caritas@gmail.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=huang.ying.caritas@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: h14j4nn7xaj4gn39z8u4gbwth1ra46ai X-HE-Tag: 1660613983-568299 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: Hi, Alistair, On Fri, Aug 12, 2022 at 1:23 PM Alistair Popple wrote: > > migrate_vma_setup() has a fast path in migrate_vma_collect_pmd() that > installs migration entries directly if it can lock the migrating page. > When removing a dirty pte the dirty bit is supposed to be carried over > to the underlying page to prevent it being lost. > > Currently migrate_vma_*() can only be used for private anonymous > mappings. That means loss of the dirty bit usually doesn't result in > data loss because these pages are typically not file-backed. However > pages may be backed by swap storage which can result in data loss if an > attempt is made to migrate a dirty page that doesn't yet have the > PageDirty flag set. > > In this case migration will fail due to unexpected references but the > dirty pte bit will be lost. If the page is subsequently reclaimed data > won't be written back to swap storage as it is considered uptodate, > resulting in data loss if the page is subsequently accessed. > > Prevent this by copying the dirty bit to the page when removing the pte > to match what try_to_migrate_one() does. > > Signed-off-by: Alistair Popple > Reported-by: Peter Xu > --- > mm/migrate_device.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/mm/migrate_device.c b/mm/migrate_device.c > index 27fb37d..d38f8a6 100644 > --- a/mm/migrate_device.c > +++ b/mm/migrate_device.c > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -211,6 +212,10 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp, > > migrate->cpages++; > > + /* Set the dirty flag on the folio now the pte is gone. */ > + if (pte_dirty(pte)) > + folio_mark_dirty(page_folio(page)); > + I think that this isn't sufficient to fix all issues. Firstly, "pte" is assigned at the begin of the loop, before the PTE is cleared via ptep_clear_flush() or ptep_get_and_clear(). That is, the pte isn't changed atomically. Between "pte" assignment and PTE clear, the PTE may become dirty. That is, we need to update pte when we clear the PTE. And I don't know why we use ptep_get_and_clear() to clear PTE if (!anon_exclusive). Why don't we need to flush the TLB? Best Regards, Huang, Ying > /* Setup special migration page table entry */ > if (mpfn & MIGRATE_PFN_WRITE) > entry = make_writable_migration_entry( > > base-commit: ffcf9c5700e49c0aee42dcba9a12ba21338e8136 > -- > git-series 0.9.1 >