linux-kernel - Re: Use higher-order pages in vmalloc

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: <CALCETrUeSgVmjgNsUg+0sAacq_VeHsEPqOkRfHkij4xmADM_5A@mail.gmail.com>
Date:   Thu, 22 Feb 2018 19:27:16 +0000
From:   Andy Lutomirski <luto@...nel.org>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Michal Hocko <mhocko@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
        LKML <linux-kernel@...r.kernel.org>,
        Christoph Hellwig <hch@...radead.org>,
        Linux-MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Kirill A. Shutemov" <kirill@...temov.name>
Subject: Re: Use higher-order pages in vmalloc

On Thu, Feb 22, 2018 at 7:19 PM, Dave Hansen <dave.hansen@...el.com> wrote:
> On 02/22/2018 11:01 AM, Andy Lutomirski wrote:
>> On x86, if you shoot down the PTE for the current stack, you're dead.
>
> *If* we were to go do this insanity for vmalloc()'d memory, we could
> probably limit it to kswapd, and also make sure that kernel threads
> don't get vmalloc()'d stacks or that we mark them in a way to say we
> never muck with them.

How does that help?  We need to make sure that the task whose stack
we're migrating is (a) not running and (b) is not being switched in or
out.  And we have to make sure that there isn't some *other* mm that
has the task's stack in ASID's TLB space.

Maybe we take some lock so the task can't run, then flush the world,
then release the lock.