All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Xinwei Hu <huxinwei@huawei.com>, Zefan Li <lizefan@huawei.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	Tianhong Ding <dingtianhong@huawei.com>,
	Steve Capper <Steve.Capper@arm.com>,
	David Woods <dwoods@ezchip.com>
Subject: Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap
Date: Fri, 8 Jul 2016 11:36:57 +0800	[thread overview]
Message-ID: <577F1FD9.1040205@huawei.com> (raw)
In-Reply-To: <20160707153741.GC27180@e104818-lin.cambridge.arm.com>



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.

> 

WARNING: multiple messages have this Message-ID (diff)
From: thunder.leizhen@huawei.com (Leizhen (ThunderTown))
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap
Date: Fri, 8 Jul 2016 11:36:57 +0800	[thread overview]
Message-ID: <577F1FD9.1040205@huawei.com> (raw)
In-Reply-To: <20160707153741.GC27180@e104818-lin.cambridge.arm.com>



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.

> 

  reply	other threads:[~2016-07-08  3:38 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-07 12:09 [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap Zhen Lei
2016-07-07 12:09 ` Zhen Lei
2016-07-07 15:37 ` Catalin Marinas
2016-07-07 15:37   ` Catalin Marinas
2016-07-08  3:36   ` Leizhen (ThunderTown) [this message]
2016-07-08  3:36     ` Leizhen (ThunderTown)
2016-07-08 13:54     ` Catalin Marinas
2016-07-08 13:54       ` Catalin Marinas
2016-07-08 15:24       ` Leizhen (ThunderTown)
2016-07-08 15:24         ` Leizhen (ThunderTown)
2016-07-08 16:13         ` Catalin Marinas
2016-07-08 16:13           ` Catalin Marinas
2016-07-11 12:43           ` Leizhen (ThunderTown)
2016-07-11 12:43             ` Leizhen (ThunderTown)
2016-07-12 15:35             ` Catalin Marinas
2016-07-12 15:35               ` Catalin Marinas
2016-07-20  2:46               ` Leizhen (ThunderTown)
2016-07-20  2:46                 ` Leizhen (ThunderTown)
2016-07-20  9:19                 ` Catalin Marinas
2016-07-20  9:19                   ` Catalin Marinas
2016-08-22  4:19                   ` Leizhen (ThunderTown)
2016-08-22  4:19                     ` Leizhen (ThunderTown)
2016-08-23 17:28                     ` Catalin Marinas
2016-08-23 17:28                       ` Catalin Marinas
2016-08-24  1:30                       ` Leizhen (ThunderTown)
2016-08-24  1:30                         ` Leizhen (ThunderTown)
2016-08-24  9:00                       ` Leizhen (ThunderTown)
2016-08-24  9:00                         ` Leizhen (ThunderTown)
2016-08-24 10:30                         ` Catalin Marinas
2016-08-24 10:30                           ` Catalin Marinas
2016-08-25  1:42                           ` Leizhen (ThunderTown)
2016-08-25  1:42                             ` Leizhen (ThunderTown)
2016-08-25  9:30                             ` Catalin Marinas
2016-08-25  9:30                               ` Catalin Marinas
2016-08-25 11:27                               ` Leizhen (ThunderTown)
2016-08-25 11:27                                 ` Leizhen (ThunderTown)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=577F1FD9.1040205@huawei.com \
    --to=thunder.leizhen@huawei.com \
    --cc=Steve.Capper@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dingtianhong@huawei.com \
    --cc=dwoods@ezchip.com \
    --cc=guohanjun@huawei.com \
    --cc=huxinwei@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.