On Fri, Jun 20, 2025 at 08:20:12AM -0700, Xin Li wrote:
> On 6/20/2025 6:53 AM, Kirill A. Shutemov wrote:
> > From: Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx>
> >
> > LASS throws a #GP for any violations except for stack register accesses,
> > in which case it throws a #SS instead. Handle this similarly to how other
> > LASS violations are handled.
> >
> > Signed-off-by: Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx>
> > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>
> > ---
> > arch/x86/kernel/traps.c | 34 ++++++++++++++++++++++++++++------
> > 1 file changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> > index 0f558d3369a3..bd8f7e72b238 100644
> > --- a/arch/x86/kernel/traps.c
> > +++ b/arch/x86/kernel/traps.c
> > @@ -866,6 +860,34 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection)
> > cond_local_irq_disable(regs);
> > }
> > +DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment)
> > +{
> > + if (cpu_feature_enabled(X86_FEATURE_LASS)) {
> > + enum kernel_gp_hint hint = GP_NO_HINT;
> > + unsigned long gp_addr;
> > +
> > + if (user_mode(regs)) {
> > + gp_user_force_sig_segv(regs, X86_TRAP_GP, error_code, GPFSTR);
> > + return;
> > + }
>
> Please add the following FRED code:
>
> if (cpu_feature_enabled(X86_FEATURE_FRED) &&
> fixup_exception(regs, X86_TRAP_SS, error_code, 0))
> return;
>
> Because the following FRED fixup
>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5105e7687ad3dffde77f6e4393b5530e83d672dc
>
> is otherwise skipped, it is interpreted as a LASS #SS before reaching
> the FRED fixup (which is indeed a userspace fault but triggered from
> a specific kernel IP as described in the commit changelog).
>
> The x86 selftest sigreturn_64 fails w/o the above fix.
Okay, will do.
> > +
> > + hint = get_kernel_gp_address(regs, &gp_addr);
> > + if (hint != GP_NO_HINT) {
> > + printk(GPFSTR ", %s 0x%lx", kernel_gp_hint_help[hint],
>
> GPFSTR?
>
> #define GPFSTR "general protection fault"
>
> It is misleading here, you need something like SSFSTR which tells
> exactly which exception caused it.
Yep, thanks for catching that!
--
Kiryl Shutsemau / Kirill A. Shutemov
