netdev - Re: [PATCH v3 09/33] nds32: Cache and TLB routines

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]

Date:   Wed, 13 Dec 2017 13:45:02 +0800
From:   Greentime Hu <green.hu@...il.com>
To:     Guo Ren <ren_guo@...ky.com>
Cc:     Greentime <greentime@...estech.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        linux-arch <linux-arch@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        Rob Herring <robh+dt@...nel.org>,
        netdev <netdev@...r.kernel.org>,
        Vincent Chen <deanbo422@...il.com>,
        DTML <devicetree@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        David Howells <dhowells@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        linux-serial@...r.kernel.org,
        Geert Uytterhoeven <geert.uytterhoeven@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Mark Rutland <mark.rutland@....com>, Greg KH <greg@...ah.com>,
        Vincent Chen <vincentc@...estech.com>
Subject: Re: [PATCH v3 09/33] nds32: Cache and TLB routines

2017-12-13 10:16 GMT+08:00 Guo Ren <ren_guo@...ky.com>:
> On Fri, Dec 08, 2017 at 05:11:52PM +0800, Greentime Hu wrote:
>> From: Greentime Hu <greentime@...estech.com>
>  [...]
>> diff --git a/arch/nds32/mm/cacheflush.c b/arch/nds32/mm/cacheflush.c
>  [...]
>> +#ifndef CONFIG_CPU_CACHE_ALIASING
>> +void update_mmu_cache(struct vm_area_struct *vma, unsigned long addr,
>> +                   pte_t * pte)
>  [...]
>> +     if (vma->vm_mm == current->active_mm) {
>> +
>> +             __nds32__mtsr_dsb(addr, NDS32_SR_TLB_VPN);
>> +             __nds32__tlbop_rwr(*pte);
>> +             __nds32__isb();
> If there is an interruption between "mtsr_dsb" and "tlbop_rwr" and a
> update_mmu_cache() is invoked again, then an error page mapping is
> set up in your tlb-buffer when tlbop_rwr is excuted from interrupt.
> Because it's another addr in NDS32_SR_TLB_VPN.
>
> It seems that tlb-hardrefill can help build tlb-buffer mapping, why you
> update it in this software way?
>

Hi, Guo Ren:

I think it should be fine if an interruption between mtsr_dsb and
tlbop_rwr because this is a optimization by sw.
The page mapping has been created and it is just not in TLB yet.
What we did is to insert this mapping to TLB by SW thus it can prevent
TLB miss one time.
It will be fine even if TLB miss. HW will walk through page table and
insert this mapping to TLB anyway.

Based on Documentation/cachetlb.txt
5) ``void update_mmu_cache(struct vm_area_struct *vma,
   unsigned long address, pte_t *ptep)``

        At the end of every page fault, this routine is invoked to
        tell the architecture specific code that a translation
        now exists at virtual address "address" for address space
        "vma->vm_mm", in the software page tables.

        A port may use this information in any way it so chooses.
        For example, it could use this event to pre-load TLB
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        translations for software managed TLB configurations.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^