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;
Date:   Mon, 24 Jan 2022 16:41:43 -0800 (PST)
From:   David Rientjes <rientjes@google.com>
To:     Zi Yan <ziy@nvidia.com>
cc:     Muchun Song <songmuchun@bytedance.com>, akpm@linux-foundation.org,
        kirill.shutemov@linux.intel.com, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, duanxiongchun@bytedance.com,
        Lars Persson <lars.persson@axis.com>
Subject: Re: [PATCH v2 2/2] mm: fix missing cache flush for all tail pages
 of THP
In-Reply-To: <5D9B52E1-A74B-4964-AACF-ADB91536C4C0@nvidia.com>
Message-ID: <91608087-a650-bf1c-a225-7afd63adf63d@google.com>
References: <20220124051752.83281-1-songmuchun@bytedance.com> <20220124051752.83281-2-songmuchun@bytedance.com> <4d5044e7-cac9-b6e6-1467-59ea6010b0f5@google.com> <5D9B52E1-A74B-4964-AACF-ADB91536C4C0@nvidia.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="447496086-858381783-1643071304=:26091"
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--447496086-858381783-1643071304=:26091
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 24 Jan 2022, Zi Yan wrote:

> >> The D-cache maintenance inside move_to_new_page() only consider one page,
> >> there is still D-cache maintenance issue for tail pages of THP. Fix this
> >> by not using flush_dcache_folio() since it is not backportable.
> >>
> >
> > The mention of being backportable suggests that we should backport this,
> > likely to 4.14+.  So should it be marked as stable?
> 
> Hmm, after more digging, I am not sure if the bug exists. For THP migration,
> flush_cache_range() is used in remove_migration_pmd(). The flush_dcache_page()
> was added by Lars Persson (cc’d) to solve the data corruption on MIPS[1],
> but THP migration is only enabled on x86_64, PPC_BOOK3S_64, and ARM64.
> 
> To make code more consistent, I guess flush_cache_range() in remove_migration_pmd()
> can be removed, since it is superseded by the flush_dcache_page() below.
> 
> The Fixes can be dropped. Let me know if I miss anything.
> 

Yeah, I don't think the Fixes needs to exist here because there doesn't 
appear to be an issue today.  We likely need to choose one of the two 
paths from above to handle the flush only in a single place.
--447496086-858381783-1643071304=:26091--