linux-kernel - Re: [PATCH v2 2/2] mm/mmu_gather: send tlb_remove_table_smp

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: <CAHbLzko2rNj8jdHVUw+kxF8Pz7b3o4im1ndoLbW611e2T3-LzA@mail.gmail.com>
Date:   Thu, 22 Jun 2023 20:38:51 -0700
From:   Yang Shi <shy828301@...il.com>
To:     Nadav Amit <nadav.amit@...il.com>, Jann Horn <jannh@...gle.com>
Cc:     Yair Podemsky <ypodemsk@...hat.com>, mtosatti@...hat.com,
        ppandit@...hat.com, David Hildenbrand <david@...hat.com>,
        "Russell King (Oracle)" <linux@...linux.org.uk>,
        Michael Ellerman <mpe@...erman.id.au>,
        Nicholas Piggin <npiggin@...il.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Heiko Carstens <hca@...ux.ibm.com>, gor@...ux.ibm.com,
        agordeev@...ux.ibm.com,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        svens@...ux.ibm.com, "David S. Miller" <davem@...emloft.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Kees Cook <keescook@...omium.org>,
        "Paul E. McKenney" <paulmck@...nel.org>, frederic@...nel.org,
        Will Deacon <will@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>, ardb@...nel.org,
        samitolvanen@...gle.com, juerg.haefliger@...onical.com,
        Arnd Bergmann <arnd@...db.de>, rmk+kernel@...linux.org.uk,
        geert+renesas@...der.be, linus.walleij@...aro.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        sebastian.reichel@...labora.com, Mike Rapoport <rppt@...nel.org>,
        aneesh.kumar@...ux.ibm.com,
        "the arch/x86 maintainers" <x86@...nel.org>,
        linux-arm-kernel@...ts.infradead.org,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        linux-s390 <linux-s390@...r.kernel.org>,
        sparclinux@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-mm <linux-mm@...ck.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] mm/mmu_gather: send tlb_remove_table_smp_sync IPI
 only to MM CPUs

On Wed, Jun 21, 2023 at 11:02 AM Nadav Amit <nadav.amit@...il.com> wrote:
>
> >
> > On Jun 20, 2023, at 7:46 AM, Yair Podemsky <ypodemsk@...hat.com> wrote:
> >
> > @@ -1525,7 +1525,7 @@ static void collapse_and_free_pmd(struct mm_struct *mm, struct vm_area_struct *v
> >                               addr + HPAGE_PMD_SIZE);
> >       mmu_notifier_invalidate_range_start(&range);
> >       pmd = pmdp_collapse_flush(vma, addr, pmdp);
> > -     tlb_remove_table_sync_one();
> > +     tlb_remove_table_sync_one(mm);
>
> Can’t pmdp_collapse_flush() have one additional argument “freed_tables”
> that it would propagate, for instance on x86 to flush_tlb_mm_range() ?
> Then you would not need tlb_remove_table_sync_one() to issue an additional
> IPI, no?
>
> It just seems that you might still have 2 IPIs in many cases instead of
> one, and unless I am missing something, I don’t see why.

The tlb_remove_table_sync_one() is used to serialize against fast GUP
for the architectures which don't broadcast TLB flush by IPI, for
example, arm64, etc. It may incur one extra IPI for x86 and some
others, but x86 virtualization needs this since the guest may not
flush TLB by sending IPI IIUC. So if the one extra IPI is really a
problem, we may be able to define an arch-specific function to deal
with it, for example, a pv ops off the top of my head. But I'm not a
virtualization expert, I'm not entirely sure whether it is the best
way or not.  But the complexity seems overkilling TBH since khugepaged
is usually not called that often.

>
>