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: Tue, 12 Mar 2024 00:33:58 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Pasha Tatashin <pasha.tatashin@...een.com>, Andy Lutomirski
 <luto@...nel.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>, the
 arch/x86 maintainers <x86@...nel.org>, Borislav Petkov <bp@...en8.de>,
 Christian Brauner <brauner@...nel.org>, bristot@...hat.com, Ben Segall
 <bsegall@...gle.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
 dianders@...omium.org, dietmar.eggemann@....com, eric.devolder@...cle.com,
 hca@...ux.ibm.com, "hch@...radead.org" <hch@...radead.org>, "H. Peter
 Anvin" <hpa@...or.com>, Jacob Pan <jacob.jun.pan@...ux.intel.com>, Jason
 Gunthorpe <jgg@...pe.ca>, jpoimboe@...nel.org, Joerg Roedel
 <jroedel@...e.de>, juri.lelli@...hat.com, Kent Overstreet
 <kent.overstreet@...ux.dev>, kinseyho@...gle.com, "Kirill A. Shutemov"
 <kirill.shutemov@...ux.intel.com>, lstoakes@...il.com, mgorman@...e.de,
 mic@...ikod.net, michael.christie@...cle.com, Ingo Molnar
 <mingo@...hat.com>, mjguzik@...il.com, "Michael S. Tsirkin"
 <mst@...hat.com>, Nicholas Piggin <npiggin@...il.com>, "Peter Zijlstra
 (Intel)" <peterz@...radead.org>, Petr Mladek <pmladek@...e.com>, Rick P
 Edgecombe <rick.p.edgecombe@...el.com>, Steven Rostedt
 <rostedt@...dmis.org>, Suren Baghdasaryan <surenb@...gle.com>, Uladzislau
 Rezki <urezki@...il.com>, vincent.guittot@...aro.org, vschneid@...hat.com
Subject: Re: [RFC 11/14] x86: add support for Dynamic Kernel Stacks

On Mon, Mar 11 2024 at 19:10, Pasha Tatashin wrote:
> On Mon, Mar 11, 2024 at 6:17 PM Andy Lutomirski <luto@...nel.org> wrote:
>> Also, I think the whole memory allocation concept in this whole
>> series is a bit odd.  Fundamentally, we *can't* block on these stack
>> faults -- we may be in a context where blocking will deadlock.  We
>> may be in the page allocator.  Panicing due to kernel stack
>> allocation would be very unpleasant.
>
> We never block during handling stack faults. There's a per-CPU page
> pool, guaranteeing availability for the faulting thread. The thread
> simply takes pages from this per-CPU data structure and refills the
> pool when leaving the CPU. The faulting routine is efficient,
> requiring a fixed number of loads without any locks, stalling, or even
> cmpxchg operations.

Is this true for any context including nested exceptions and #NMI?

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ