From patchwork Fri Jul 8 13:54:47 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Catalin Marinas X-Patchwork-Id: 71674 Delivered-To: patch@linaro.org Received: by 10.140.28.4 with SMTP id 4csp464204qgy; Fri, 8 Jul 2016 06:55:07 -0700 (PDT) X-Received: by 10.98.192.135 with SMTP id g7mr10383940pfk.64.1467986107270; Fri, 08 Jul 2016 06:55:07 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w5si1120426paa.215.2016.07.08.06.55.06; Fri, 08 Jul 2016 06:55:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755502AbcGHNzC (ORCPT + 30 others); Fri, 8 Jul 2016 09:55:02 -0400 Received: from foss.arm.com ([217.140.101.70]:42988 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754985AbcGHNyw (ORCPT ); Fri, 8 Jul 2016 09:54:52 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 34E4028; Fri, 8 Jul 2016 06:55:52 -0700 (PDT) Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com [10.1.203.148]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F30DC3F213; Fri, 8 Jul 2016 06:54:49 -0700 (PDT) Date: Fri, 8 Jul 2016 14:54:47 +0100 From: Catalin Marinas To: "Leizhen (ThunderTown)" Cc: Steve Capper , David Woods , Tianhong Ding , Will Deacon , linux-kernel , Xinwei Hu , Zefan Li , Hanjun Guo , linux-arm-kernel Subject: Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap Message-ID: <20160708135447.GB22099@e104818-lin.cambridge.arm.com> References: <1467893344-8352-1-git-send-email-thunder.leizhen@huawei.com> <20160707153741.GC27180@e104818-lin.cambridge.arm.com> <577F1FD9.1040205@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <577F1FD9.1040205@huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 08, 2016 at 11:36:57AM +0800, Leizhen (ThunderTown) wrote: > On 2016/7/7 23:37, Catalin Marinas wrote: > > On Thu, Jul 07, 2016 at 08:09:04PM +0800, Zhen Lei wrote: > >> At present, PG_dcache_clean is only cleared when the related huge page > >> is about to be freed. But sometimes, there maybe a process is in charge > >> to copy binary codes into a shared memory, and notifies other processes > >> to execute base on that. For the first time, there is no problem, because > >> the default value of page->flags is PG_dcache_clean cleared. So the cache > >> will be maintained at the time of set_pte_at for other processes. But if > >> the content of the shared memory have been updated again, there is no > >> cache operations, because the PG_dcache_clean is still set. > >> > >> For example: > >> Process A > >> open a hugetlbfs file > >> mmap it as a shared memory > >> copy some binary codes into it > >> munmap > >> > >> Process B > >> open the hugetlbfs file > >> mmap it as a shared memory, executable > >> invoke the functions in the shared memory > >> munmap > >> > >> repeat the above steps. > > > > Does this work as you would expect with small pages (and for example > > shared file mmap)? I don't want to have a different behaviour between > > small and huge pages. > > The small pages also have this problem, I will try to fix it too. Have you run the above tests on a standard file (with small pages)? It's strange that we haven't hit this so far with gcc or something else generating code (unless they don't use mmap but just sequential writes). If both cases need solving, we might better move the fix in the __sync_icache_dcache() function. Untested: ------------8<---------------- ----------------8<--------------------- BTW, can you make your tests (source) available somewhere? Thanks. -- Catalin diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c index dbd12ea8ce68..c753fa804165 100644 --- a/arch/arm64/mm/flush.c +++ b/arch/arm64/mm/flush.c @@ -75,7 +75,8 @@ void __sync_icache_dcache(pte_t pte, unsigned long addr) if (!page_mapping(page)) return; - if (!test_and_set_bit(PG_dcache_clean, &page->flags)) + if (!test_and_set_bit(PG_dcache_clean, &page->flags) || + PageDirty(page)) sync_icache_aliases(page_address(page), PAGE_SIZE << compound_order(page)); else if (icache_is_aivivt())