On Fri, 2025-03-14 at 11:21 +0100, Ingo Molnar wrote:
>
> I've applied patch #1 back to tip:x86/boot.
>
> I've skipped the -v7 versions of patch #2 and #3 because AFAICS you've
> changed exc_handler already, so a backmerge of this annotation fix
> wouldn't be enough.
I haven't (yet) changed ex
* David Woodhouse wrote:
> On Thu, 2025-03-13 at 19:58 +, David Woodhouse wrote:
> >
> > Reproduced that by going back to x86-64 defconfig.
>
> Turns out the unret check doesn't even run unless CONFIG_DEBUG_ENTRY is
> enabled (which enables CONFIG_NOINSTR_VALIDATION and thus runs objtool
On Thu, 2025-03-13 at 19:58 +, David Woodhouse wrote:
>
> Reproduced that by going back to x86-64 defconfig.
Turns out the unret check doesn't even run unless CONFIG_DEBUG_ENTRY is
enabled (which enables CONFIG_NOINSTR_VALIDATION and thus runs objtool
on vmlinux.o). Which is why I didn't see
On Thu, 2025-03-13 at 11:54 +0100, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> > I applied the first 3 patches to tip:x86/boot for
> > phased-risk-reduction reasons, and because I had some questions and
> > suggestions starting at patch #4.
>
> So there's a new objtool build warning from t
* Ingo Molnar wrote:
> I applied the first 3 patches to tip:x86/boot for
> phased-risk-reduction reasons, and because I had some questions and
> suggestions starting at patch #4.
So there's a new objtool build warning from the new exc_handler code:
vmlinux.o: warning: objtool: exc_handler+
* David Woodhouse wrote:
> Debugging kexec failures is painful, as anything going wrong in execution
> of the critical relocate_kernel() function tends to just lead to a triple
> fault. Thus leading to *weeks* of my life that I won't get back. Having
> hacked something up for my own use, I figu
