linux-kernel - Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160720091939.GA25890@e104818-lin.cambridge.arm.com>
Date:	Wed, 20 Jul 2016 10:19:39 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	"Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>
Cc:	Steve Capper <Steve.Capper@....com>,
	David Woods <dwoods@...hip.com>,
	Hanjun Guo <guohanjun@...wei.com>,
	Will Deacon <will.deacon@....com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Xinwei Hu <huxinwei@...wei.com>, Zefan Li <lizefan@...wei.com>,
	Tianhong Ding <dingtianhong@...wei.com>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is
 dirty when munmap

On Wed, Jul 20, 2016 at 10:46:27AM +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<---------------------
> 
> 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.

The reason I'm not sending it is that I don't fully understand how it
solves the problem for a shared file mmap(), not just hugetlbfs. As I
said in an earlier email: 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.

> 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);

Yes, and set_pte_at() would be called as a result of a page fault when
accessing the mmap'ed file.

-- 
Catalin