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

[Ard Biesheuvel]

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.