[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0bcb98ed-0e35-7242-377a-fee4eb751452@linux.alibaba.com>
Date: Sat, 2 Jul 2022 18:12:33 +0800
From: "guanghui.fgh" <guanghuifeng@...ux.alibaba.com>
To: Catalin Marinas <catalin.marinas@....com>
Cc: baolin.wang@...ux.alibaba.com, will@...nel.org,
akpm@...ux-foundation.org, david@...hat.com, jianyong.wu@....com,
james.morse@....com, quic_qiancai@...cinc.com,
christophe.leroy@...roup.eu, jonathan@...ek.ca,
mark.rutland@....com, thunder.leizhen@...wei.com,
anshuman.khandual@....com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, rppt@...nel.org,
geert+renesas@...der.be, ardb@...nel.org, linux-mm@...ck.org,
yaohongbo@...ux.alibaba.com, alikernel-developer@...ux.alibaba.com
Subject: Re: [PATCH v3] arm64: mm: fix linear mapping mem access performance
degradation
Thanks.
在 2022/7/2 1:24, Catalin Marinas 写道:
> On Thu, Jun 30, 2022 at 06:50:22PM +0800, Guanghui Feng wrote:
>> +static void init_pmd_remap(pud_t *pudp, unsigned long addr, unsigned long end,
>> + phys_addr_t phys, pgprot_t prot,
>> + phys_addr_t (*pgtable_alloc)(int), int flags)
>> +{
>> + unsigned long next;
>> + pmd_t *pmdp;
>> + phys_addr_t map_offset;
>> + pmdval_t pmdval;
>> +
>> + pmdp = pmd_offset(pudp, addr);
>> + do {
>> + next = pmd_addr_end(addr, end);
>> +
>> + if (!pmd_none(*pmdp) && pmd_sect(*pmdp)) {
>> + phys_addr_t pte_phys = pgtable_alloc(PAGE_SHIFT);
>> + pmd_clear(pmdp);
>> + pmdval = PMD_TYPE_TABLE | PMD_TABLE_UXN;
>> + if (flags & NO_EXEC_MAPPINGS)
>> + pmdval |= PMD_TABLE_PXN;
>> + __pmd_populate(pmdp, pte_phys, pmdval);
>> + flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>
> This doesn't follow the architecture requirements for "break before
> make" when changing live page tables. While it may work, it risks
> triggering a TLB conflict abort. The correct sequence normally is:
>
> pmd_clear();
> flush_tlb_kernel_range();
> __pmd_populate();
>
> However, do we have any guarantees that the kernel doesn't access the
> pmd range being unmapped temporarily? The page table itself might live
> in one of these sections, so set_pmd() etc. can get a translation fault.
>
Thanks. I'll follow this.
I'll resend the path as soon as possible.
Powered by blists - more mailing lists