Re: [PATCH 9/9] x86/kexec: Use typedef for relocate_kernel_fn function prototype

[David Woodhouse]

On 17 December 2024 11:14:29 CET, Ard Biesheuvel <ardb at kernel.org> wrote:
>On Tue, 17 Dec 2024 at 11:07, David Woodhouse <dwmw2 at infradead.org> wrote:
>>
>> On 17 December 2024 10:54:19 CET, Ard Biesheuvel <ardb at kernel.org> wrote:
>> >On Tue, 17 Dec 2024 at 10:42, David Woodhouse <dwmw2 at infradead.org> wrote:
>> >> Hm, I am perfectly happy to believe that my memory is failing me, especially when it comes to specifics of i386 assembler code. But are you also telling me that
>> >> <https://kernelnewbies.org/FAQ/asmlinkage> is a lie?
>> >>
>> >
>> >It seems wildly out of date, at least.
>> >
>> >Commit 96a388de5dc53a8b2 from 2007 removed the asmlinkage definition
>> >containing regparm(0) from include/asm-i386/linkage.h, and I'm not
>> >convinced it was ever sound to conflate linkage with calling
>> >convention like that. Today, asmlinkage evaluates to 'extern "C"' when
>> >using a C++ compiler, which is also not part of the type.
>> >
>> >However, I failed to notice that this just moves code around, and only
>> >applies to 32-bit in the first place. So I won't waste any more of
>> >your time obsessing over this.
>>
>> Too late :)
>>
>> You've already made me concerned about what the calling convention *is* for relocate_kernel() on i386. Because if asmlinkage doesn't mean regparm(0) any more and the i386 kernel is still built with -mregparm=3, then how does the asm code (which seems to believe all its arguments are on the stack) actually work?
>>
>> It seems slightly unlikely that kexec on i386 has just been broken since 2007 but I'm not sure I'd completely rule it out.
>>
>> So now I guess I have to actually build a 32-bit userspace test case and *test* it.
>>
>> And that means I no longer have any excuse for not doing all the same cleanups in the i386 version of the code that I've done for x86_64...
>>
>> Thanks for that :)
>>
>
>Actually, asmlinkage still means regparm(0) on i386, so I'm going to
>have to apologise again, for my poor git foo this time.

Heh, no problem.

I'm pleased to find my memory wasn't failing me after all, so I might have a bit more time left before they put me out to pasture.

I'll take that win :)