Re: [PATCH v2 12/13] x86: Add support for dynamic kernel stacks via FRED

[H. Peter Anvin]

On June 28, 2026 9:46:32 AM PDT, Thomas Gleixner <tglx@xxxxxxxxxx> wrote:
>On Fri, Jun 26 2026 at 21:05, David Stevens wrote:
>> On Fri, Jun 26, 2026 at 3:39 PM Thomas Gleixner <tglx@xxxxxxxxxx> wrote:
>> That is definitely a situation that could happen, I hadn't thought of
>> it. Luckily, I don't think we need NMI-safe re-entrancy to handle
>> this, since an NMI on SL0 couldn't have interrupted a dynamic stack
>> fault.
>
>Correct.
>
>>> As a consequence you copy stack data around to the same place, which
>>> should be benign, but it is well understood that memcpy() source and
>>> destination areas _must_ not overlap. That's UB, no?
>>>
>>> I know that should not happen, but that doesn't make it less UB :)
>>
>> That sort of fault would probably end up either with a
>> page_fault_oops() or risk a context switch with SL>0, but we shouldn't
>> make debugging harder with UB.
>
>Definitely not :)
>
>You can avoid quite some of the problems right in the ASM entry code.
>Instead of checking event type/vector and then going to the stack switch
>logic, you can check the stack level on which the event happened
>first. If it's not 0, then there is nothing to do.
>
>

To be fair, for this *specific* case, memmove() does exist for a reason :)