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: Steve Capper <Steve.Capper@arm.com>,
	David Woods <dwoods@ezchip.com>,
	Tianhong Ding <dingtianhong@huawei.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Xinwei Hu <huxinwei@huawei.com>, Zefan Li <lizefan@huawei.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap
Date: Wed, 20 Jul 2016 10:46:27 +0800	[thread overview]
Message-ID: <578EE603.9020206@huawei.com> (raw)
In-Reply-To: <20160712153535.GH22183@e104818-lin.cambridge.arm.com>



On 2016/7/12 23:35, Catalin Marinas wrote:
> On Mon, Jul 11, 2016 at 08:43:32PM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/7/9 0:13, Catalin Marinas wrote:
>>> On Fri, Jul 08, 2016 at 11:24:26PM +0800, Leizhen (ThunderTown) wrote:
>>>> On 2016/7/8 21:54, Catalin Marinas wrote:
>>>>> ------------8<----------------
>>>>> 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())
>>>>> ----------------8<---------------------
Hi, Catalin:
  Do you plan to send this patch? My colleagues told me that if our patches are quite
different, it should be Signed-off-by you.

  I searched all Linux source code, __sync_icache_dcache is only called by set_pte_at,
and some check conditions(especially pte_exec) will limit its impact.

	if (pte_user(pte) && pte_exec(pte) && !pte_special(pte))
		__sync_icache_dcache(pte, addr);

>>>>>
>>>>> BTW, can you make your tests (source) available somewhere?
>>>>
>>>> Both cases worked well with this patch.
>>>
>>> Now I'm even more confused ;). IIUC, after an msync() in user space we
>>> should flush the pages to disk via write_cache_pages(). This function
>>> calls clear_page_dirty_for_io() after which PageDirty() is no longer
>>> true. I can't tell how a subsequent mmap() can see the written pages as
>>> dirty.
>>
>> As my tracing, both cases invoked empty function.
>>
>> int vfs_fsync_range(struct file *file, loff_t start, loff_t end, int datasync)
>> 	......
>> 	return file->f_op->fsync(file, start, end, datasync);
>> }
>>
>> const struct file_operations hugetlbfs_file_operations = {
>> 	.fsync			= noop_fsync,
>>
>> static const struct file_operations shmem_file_operations = {
>> 	.mmap		= shmem_mmap,
>> #ifdef CONFIG_TMPFS
>> 	.fsync		= noop_fsync,
> 
> I was referring to standard filesystem (e.g. ext4) writes where, IIUC,
> the PageDirty() status is cleared after I/O but it's not necessarily
> removed from the page cache.
> 

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: Wed, 20 Jul 2016 10:46:27 +0800	[thread overview]
Message-ID: <578EE603.9020206@huawei.com> (raw)
In-Reply-To: <20160712153535.GH22183@e104818-lin.cambridge.arm.com>



On 2016/7/12 23:35, Catalin Marinas wrote:
> On Mon, Jul 11, 2016 at 08:43:32PM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/7/9 0:13, Catalin Marinas wrote:
>>> On Fri, Jul 08, 2016 at 11:24:26PM +0800, Leizhen (ThunderTown) wrote:
>>>> On 2016/7/8 21:54, Catalin Marinas wrote:
>>>>> ------------8<----------------
>>>>> 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())
>>>>> ----------------8<---------------------
Hi, Catalin:
  Do you plan to send this patch? My colleagues told me that if our patches are quite
different, it should be Signed-off-by you.

  I searched all Linux source code, __sync_icache_dcache is only called by set_pte_at,
and some check conditions(especially pte_exec) will limit its impact.

	if (pte_user(pte) && pte_exec(pte) && !pte_special(pte))
		__sync_icache_dcache(pte, addr);

>>>>>
>>>>> BTW, can you make your tests (source) available somewhere?
>>>>
>>>> Both cases worked well with this patch.
>>>
>>> Now I'm even more confused ;). IIUC, after an msync() in user space we
>>> should flush the pages to disk via write_cache_pages(). This function
>>> calls clear_page_dirty_for_io() after which PageDirty() is no longer
>>> true. I can't tell how a subsequent mmap() can see the written pages as
>>> dirty.
>>
>> As my tracing, both cases invoked empty function.
>>
>> int vfs_fsync_range(struct file *file, loff_t start, loff_t end, int datasync)
>> 	......
>> 	return file->f_op->fsync(file, start, end, datasync);
>> }
>>
>> const struct file_operations hugetlbfs_file_operations = {
>> 	.fsync			= noop_fsync,
>>
>> static const struct file_operations shmem_file_operations = {
>> 	.mmap		= shmem_mmap,
>> #ifdef CONFIG_TMPFS
>> 	.fsync		= noop_fsync,
> 
> I was referring to standard filesystem (e.g. ext4) writes where, IIUC,
> the PageDirty() status is cleared after I/O but it's not necessarily
> removed from the page cache.
> 

  reply	other threads:[~2016-07-20  2:47 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)
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) [this message]
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=578EE603.9020206@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.