Messages in this thread | | | Date | Wed, 20 Jul 2016 10:19:39 +0100 | From | Catalin Marinas <> | 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
| |