From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754112AbcGHDiU (ORCPT ); Thu, 7 Jul 2016 23:38:20 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:1434 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753817AbcGHDiQ (ORCPT ); Thu, 7 Jul 2016 23:38:16 -0400 Subject: Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap To: Catalin Marinas References: <1467893344-8352-1-git-send-email-thunder.leizhen@huawei.com> <20160707153741.GC27180@e104818-lin.cambridge.arm.com> CC: Will Deacon , linux-arm-kernel , linux-kernel , Xinwei Hu , Zefan Li , Hanjun Guo , Tianhong Ding , Steve Capper , David Woods From: "Leizhen (ThunderTown)" Message-ID: <577F1FD9.1040205@huawei.com> Date: Fri, 8 Jul 2016 11:36:57 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160707153741.GC27180@e104818-lin.cambridge.arm.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.23.164] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.577F1FE6.003D,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 925ebe5d6e84ba3f030e1fdc21b06d29 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. >