linux-kernel - Re: [v3 2/3] mm: Defer TLB flush by keeping both src and dst folios at migration

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: <20231030224037.GA900@system.software.com>
Date:   Tue, 31 Oct 2023 07:40:37 +0900
From:   Byungchul Park <byungchul@...com>
To:     Nadav Amit <namit@...are.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        "kernel_team@...ynix.com" <kernel_team@...ynix.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "ying.huang@...el.com" <ying.huang@...el.com>,
        "xhao@...ux.alibaba.com" <xhao@...ux.alibaba.com>,
        "mgorman@...hsingularity.net" <mgorman@...hsingularity.net>,
        "hughd@...gle.com" <hughd@...gle.com>,
        "willy@...radead.org" <willy@...radead.org>,
        "david@...hat.com" <david@...hat.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
Subject: Re: [v3 2/3] mm: Defer TLB flush by keeping both src and dst folios
 at migration

On Mon, Oct 30, 2023 at 03:58:44PM +0000, Nadav Amit wrote:
> 
> 
> > On Oct 30, 2023, at 2:51 PM, Byungchul Park <byungchul@...com> wrote:
> > 
> > I really spent a lot of time hesitating whether splitting it or not.
> > However, the test result cannot be stable without those. I'm still
> > confused. I think the test result should be stable at each commit,
> > right?
> 
> Of course. You can extract the optimization we mentioned, and perhaps
> have more preparatory patches.
> 
> Just a couple of comments that may also help breaking the patches:
> 
> 1. The “stopping” logic is a bit not great. Try to see if you can
> somehow use shrinker or OOM infrastructure instead.

The stopping means "temporarily pausing" expanding migrc's pending
queue, not shrinking folios.. Yeah my fault. I will rename it another
not to make guys get it wrong.

> 2. Regarding “overflows”, it’s not always a question of whether an
> overflow would happen naturally, but whether a malicious process can
> trigger it.

I understand what you are worried about. However, it's intended that
the variable is going to overflow. And the overflow doesn't matter if we
are aware of it and careful in handling it. See time_after() in
include/linux/jiffies.h. That would help you understand what I mean.

	Byungchul
> 
> Regards,
> Nadav
>