From: Mukesh R <mrathor@linux.microsoft.com>
To: Ard Biesheuvel <ardb@kernel.org>,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
dave.hansen@linux.intel.com, x86@kernel.org,
"H . Peter Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v1 5/6] x86/hyperv: Implement hypervisor ram collection into vmcore
Date: Fri, 27 Feb 2026 12:05:13 -0800 [thread overview]
Message-ID: <6a601546-a26f-79f6-a3b0-be145dfa7781@linux.microsoft.com> (raw)
In-Reply-To: <eb1c44d7-2664-4269-8824-e90e5a8494b2@app.fastmail.com>
On 2/25/26 23:44, Ard Biesheuvel wrote:
>
> On Wed, 25 Feb 2026, at 23:27, Mukesh R wrote:
>> On 2/21/26 08:43, Ard Biesheuvel wrote:
>>> Just spotted this code in v7.0-rc
>>>
>>> On Wed, 10 Sep 2025, at 02:10, Mukesh Rathor wrote:
>>> ...
>>>
>>>> +static asmlinkage void __noreturn hv_crash_c_entry(void)
>>>
>>> 'asmlinkage' means that the function may be called from another compilation unit written in assembler, but it doesn't actually evaluate to anything in most cases. Combining it with 'static' makes no sense whatsoever.
>>
>> 'static' means scope is limited to the file. Common in cases where function
>> pointers are used, like here in this file way below.
>>
>> Like the comment says:
>> "This is the C entry point from the asm glue code after...."
>>
>> IOW, called from assembly function (asm == assembly).
>>
>
> I wasn't asking you to explain what 'static' means. I was explaining to you that asmlinkage means 'external linkage' whereas 'static' means the opposite, and so combining them makes no sense.
>
>
>>>
>>>> +{
>>>> + struct hv_crash_ctxt *ctxt = &hv_crash_ctxt;
>>>> +
>>>> + /* first thing, restore kernel gdt */
>>>> + native_load_gdt(&ctxt->gdtr);
>>>> +
>>>> + asm volatile("movw %%ax, %%ss" : : "a"(ctxt->ss));
>>>> + asm volatile("movq %0, %%rsp" : : "m"(ctxt->rsp));
>>>> +
>>>
>>> This code is truly very broken. You cannot enter a C function without a stack, and assign RSP half way down the function. Especially after allocating local variables and/or calling other functions - it may happen to work in most cases, but it is very fragile. (Other architectures have the concept of 'naked' functions for this purpose but x86 does not)
>>
>> Local variable refers to static bss struct. IOW,
>>
>> asm volatile("movq %0, %%rsp" : : "m"(ctxt->rsp));
>>
>> same as:
>> asm volatile("movq %0, %%rsp" : : "m"(&hv_crash_ctxt.rsp));
>>
>>
>
> No, it is *not* the same. In practice, the compiler might perform this substitution, but there is no guarantee that this happens.
>
>
>>> IOW, this whole function should be written in asm.
>>>> + asm volatile("movw %%ax, %%ds" : : "a"(ctxt->ds));
>>>> + asm volatile("movw %%ax, %%es" : : "a"(ctxt->es));
>>>> + asm volatile("movw %%ax, %%fs" : : "a"(ctxt->fs));
>>>> + asm volatile("movw %%ax, %%gs" : : "a"(ctxt->gs));
>>>> +
>>>> + native_wrmsrq(MSR_IA32_CR_PAT, ctxt->pat);
>>>> + asm volatile("movq %0, %%cr0" : : "r"(ctxt->cr0));
>>>> +
>>>> + asm volatile("movq %0, %%cr8" : : "r"(ctxt->cr8));
>>>> + asm volatile("movq %0, %%cr4" : : "r"(ctxt->cr4));
>>>> + asm volatile("movq %0, %%cr2" : : "r"(ctxt->cr4));
>>>> +
>>>> + native_load_idt(&ctxt->idtr);
>>>> + native_wrmsrq(MSR_GS_BASE, ctxt->gsbase);
>>>> + native_wrmsrq(MSR_EFER, ctxt->efer);
>>>> +
>>>> + /* restore the original kernel CS now via far return */
>>>> + asm volatile("movzwq %0, %%rax\n\t"
>>>> + "pushq %%rax\n\t"
>>>> + "pushq $1f\n\t"
>>>> + "lretq\n\t"
>>>> + "1:nop\n\t" : : "m"(ctxt->cs) : "rax");
>>>> +
>>>> + /* We are in asmlinkage without stack frame,
>>>
>>> You just switched to __KERNEL_CS via the stack.
>>
>> compiler doesn't know that.
>>
>
> So? But does it means to 'be in asmlinkage' in your interpretation? Did you check what 'asmlinkage' actually evaluates to?
>
> I am not asking you to justify why this broken code works in practice, I am asking you to fix it.
STOP bossing me! I am not your servant nor your slave. And you are not the
only genius around here.
Now, many people looked at this code before it was merged and no one really
thought any self respecting compiler in modern times would create an issue
here. Still, I see the remote possibility of that happening. All you had
to do was to show your concern and suggest using __naked here (which looks
like we all missed, or maybe it came after the code was written), and it
would have been addressed. This is x64 specific code for very special case
of hyperv or kernel-on-hyperv crashing.
In future if you choose to correspond, watch your tone!
>>>> hence make a C function
>>>> + * call which will buy stack frame to restore the tss or clear PT
>>>> entry.
>>>> + */
>>>
>>> Where does one buy a stack frame?
>>
>> A stack market :). Callee will create stack frame now that rsp is
>> setup.
>>
>
> This code is beyond broken. Please propose fixes rather than try to argue why carrying broken code like this is acceptable.
next prev parent reply other threads:[~2026-02-27 20:05 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 0:10 [PATCH v1 0/6] Hyper-V: Implement hypervisor core collection Mukesh Rathor
2025-09-10 0:10 ` [PATCH v1 1/6] x86/hyperv: Rename guest crash shutdown function Mukesh Rathor
2025-09-10 0:10 ` [PATCH v1 2/6] hyperv: Add two new hypercall numbers to guest ABI public header Mukesh Rathor
2025-09-10 0:10 ` [PATCH v1 3/6] hyperv: Add definitions for hypervisor crash dump support Mukesh Rathor
2025-09-15 17:54 ` Michael Kelley
2025-09-16 1:15 ` Mukesh R
2025-09-18 23:52 ` Michael Kelley
2025-09-10 0:10 ` [PATCH v1 4/6] x86/hyperv: Add trampoline asm code to transition from hypervisor Mukesh Rathor
2025-09-15 17:55 ` Michael Kelley
2025-09-16 21:30 ` Mukesh R
2025-09-18 23:52 ` Michael Kelley
2025-09-19 9:06 ` Borislav Petkov
2025-09-19 19:09 ` Mukesh R
2025-09-10 0:10 ` [PATCH v1 5/6] x86/hyperv: Implement hypervisor ram collection into vmcore Mukesh Rathor
2025-09-15 17:55 ` Michael Kelley
2025-09-17 1:13 ` Mukesh R
2025-09-17 20:37 ` Mukesh R
2025-09-18 23:53 ` Michael Kelley
2025-09-19 2:32 ` Mukesh R
2025-09-19 19:48 ` Michael Kelley
2025-09-20 1:42 ` Mukesh R
2025-09-23 1:35 ` Michael Kelley
2025-09-18 17:11 ` Stanislav Kinsburskii
2026-02-21 16:43 ` Ard Biesheuvel
2026-02-25 22:27 ` Mukesh R
2026-02-26 7:44 ` Ard Biesheuvel
2026-02-27 20:05 ` Mukesh R [this message]
2026-02-27 21:37 ` Wei Liu
2026-02-27 22:10 ` Ard Biesheuvel
2025-09-10 0:10 ` [PATCH v1 6/6] x86/hyperv: Enable build of hypervisor crashdump collection files Mukesh Rathor
2025-09-13 4:53 ` kernel test robot
2025-09-13 5:57 ` kernel test robot
2025-09-15 17:56 ` Michael Kelley
2025-09-17 1:15 ` Mukesh R
2025-09-18 23:53 ` Michael Kelley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a601546-a26f-79f6-a3b0-be145dfa7781@linux.microsoft.com \
--to=mrathor@linux.microsoft.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kys@microsoft.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox