Re: [PATCH V5 3/7] x86/entry: Move PUSH_AND_CLEAR_REGS out of error_entry()
From: Lai Jiangshan
Date: Tue Apr 12 2022 - 09:53:12 EST
On Tue, Apr 12, 2022 at 9:26 PM Borislav Petkov <bp@xxxxxxxxx> wrote:
>
> On Tue, Apr 12, 2022 at 08:15:37PM +0800, Lai Jiangshan wrote:
> > From: Lai Jiangshan <jiangshan.ljs@xxxxxxxxxxxx>
> >
> > error_entry() doesn't handle the stack balanced.
>
> What does that mean?
For a normal function, e.g. a function complied from a C function,
the stack will return to its original place when the function
returns. The size of memory pushed and popped are the same in
a function.
>
> > It includes
> > PUSH_AND_CLEAR_REGS which is commonly needed for all IDT entries and
> > can't pop the regs before it returns.
> >
> > Move PUSH_AND_CLEAR_REGS out of error_entry() and make error_entry()
> > works on the stack normally.
> >
> > After this, XENPV doesn't need error_entry() since PUSH_AND_CLEAR_REGS
> > is moved out and error_entry() can be converted to C code in future
> > since it doesn't fiddle the stack.
>
> This is not a justification for this size increase:
>
> text data bss dec hex filename
> 16060616 128131358 36384888 180576862 ac3625e vmlinux.before
> 16065626 128131358 36380792 180577776 ac365f0 vmlinux.after
>
> ~5K text increase already with my tailored config.
>
> You can have a asm_error_entry(), written in asm, which does the regs
> pushing and which calls error_entry() - the latter being the C version.
> And no need for the size increase.
The mapped size for the text is always 2M when the kernel is booted
since it is 2M-aligned. So I don't think the size is a concern.
The only concern is the footprint when different interrupts and
exceptions happen heavily at the same time. In this case, different
copies of PUSH_AND_CLEAR_REGS in the text will be touched.
For example, a heavy page fault and IPI or timer at the same time.
I'm not sure if it is a real case.
I'm Okay with asm_error_entry(). And also we can use an ASM function
containing PUSH_AND_CLEAR_REGS only.
Thanks
Lai