Re: [PATCH RFC v2 04/29] mm: asi: Add infrastructure for boot-time enablement

On Fri, Jan 10, 2025 at 06:40:30PM +, Brendan Jackman wrote: > Add a boot time parameter to control the newly added X86_FEATURE_ASI. > "asi=on" or "asi=off" can be used in the kernel command line to enable > or disable ASI at boot time. If not specified, ASI enablement depends > on CONFIG_ADDRE

Re: [PATCH RFC v2 03/29] mm: asi: Introduce ASI core API

On Wed, Feb 19, 2025 at 02:53:03PM +0100, Brendan Jackman wrote: > Argh, sorry, GMail switched back to HTML mode somehow. Maybe I have to > get a proper mail client after all. Yap, wouldn't be such a bad idea. And yes, it ain't easy - we have a whole doc about it: Documentation/process/email-clie

Re: [PATCH RFC v2 03/29] mm: asi: Introduce ASI core API

On Fri, Jan 10, 2025 at 06:40:29PM +, Brendan Jackman wrote: > Subject: Re: [PATCH RFC v2 03/29] mm: asi: Introduce ASI core API x86/asi: ... > Introduce core API for Address Space Isolation (ASI). Kernel address > space isolation provides the ability to run some kernel > code with a restric

Re: [PATCH RFC v2 01/29] mm: asi: Make some utility functions noinstr compatible

On Fri, Jan 10, 2025 at 06:40:27PM +, Brendan Jackman wrote: > Subject: Re: [PATCH RFC v2 01/29] mm: asi: Make some utility functions > noinstr compatible The tip tree preferred format for patch subject prefixes is 'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:', 'genirq

Re: [PATCH RFC v2 01/29] mm: asi: Make some utility functions noinstr compatible

On Thu, Jan 16, 2025 at 02:22:42PM +0100, Brendan Jackman wrote: > Sure. I'm actually not even sure that for a [PATCH]-quality thing this > cross-cutting commit even makes sense - once we've decided on the > general way to solve this problem, perhaps the changes should just be > part of the commit

Re: [PATCH RFC v2 02/29] x86: Create CONFIG_MITIGATION_ADDRESS_SPACE_ISOLATION

On Fri, Jan 10, 2025 at 06:40:28PM +, Brendan Jackman wrote: > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index > 7b9a7e8f39acc8e9aeb7d4213e87d71047865f5c..5a50582eb210e9d1309856a737d32b76fa1bfc85 > 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -2519,6 +2519,20 @@ conf

Re: [PATCH RFC v2 01/29] mm: asi: Make some utility functions noinstr compatible

On Thu, Jan 16, 2025 at 01:18:58AM +0100, Borislav Petkov wrote: > Long story short, lemme try to poke around tomorrow to try to figure out what > actually happens. It could be caused by the part of Rik's patches and this one > inlining things. We'll see... Looks transient.

Re: [PATCH v7] mm/memblock: Add memblock_alloc_or_panic interface

On Mon, Dec 23, 2024 at 03:32:01PM +0800, Weikang Guo wrote: > First of all, thank you for your reminder and patience. In fact, this > is the first time I received a patch discussion when submitting a > patch. > About Reviewed-by or Acked-by tags, I will not add it myself in the > future. Regarding

Re: [patch 02/17] x86/cpu: Switch to arch_cpu_finalize_init()

On Wed, Jun 14, 2023 at 11:53:50AM +0200, Thomas Gleixner wrote: > That's the wrong order. mitigations must come before the smt > update. Thanks to Boris for spotting it. Right, with that fixed the ordering looks good now. Reviewed-by: Borislav Petkov (AMD) -- Regards/Gruss, Bo

Re: [patch 01/17] init: Provide arch_cpu_finalize_init()

Just typos: On Wed, Jun 14, 2023 at 01:39:22AM +0200, Thomas Gleixner wrote: > check_bugs() has become a dump ground for all sorts of activities to "dumping ground" > finalize the CPU initialization before running the rest of the init code. > > Most are empty, a few do actual bug checks, some d

Re: [PATCH v7 13/41] mm: Make pte_mkwrite() take a VMA

On Mon, Feb 27, 2023 at 02:29:29PM -0800, Rick Edgecombe wrote: > [0] > https://lore.kernel.org/lkml/0e29a2d0-08d8-bcd6-ff26-4bea0e403...@redhat.com/#t I guess that sub-thread about how you arrived at this "pass a VMA" decision should be in the Link tag. But that's for the committer, I'd say. Th