On Tue, 17 Dec 2024 at 11:07, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > > On 17 December 2024 10:54:19 CET, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > >On Tue, 17 Dec 2024 at 10:42, David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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.
