Re: [PATCHv8 14/17] x86/traps: Handle LASS thrown #SS

Kirill A. Shutemov
2025-07-03T11:31:46Z

On Wed, Jul 02, 2025 at 01:05:17PM -0700, Sohil Mehta wrote:
> On 7/2/2025 6:27 AM, Kirill A. Shutemov wrote:
>
> >>
> >> Maybe I've misunderstood something:
> >>
> >> Is the underlying assumption here that #SS were previously only
> >> generated by userspace, but now they can also be generated by the
> >> kernel? And we want the kernel generated #SS to behave the same as the #GP?
> >
> > It can be generated by both kernel and userspace if RSP gets corrupted.
> >
> > So far, do_error_trap() did the trick, handling what has to be handled.
> > LASS requires a bit more, though.
> >
> Thank you for the information! The discussion in the other thread helped
> clarify my confusion about the new FRED specific fixup outside the LASS
> check.
>
> IIUC, for kernel generated #SS, the prior code in do_error_trap()
> would've done a few things such as notify_die() and
> cond_local_irq_enable() before calling die().

cond_local_irq_enable() need to happen if we want to do something
sleepable during exception handling. It is not the case here.

notify_die() will be called die_addr()->__die_body()->notify_die().

> The new code now directly calls die_addr(). Are we changing the behavior
> for legacy kernel #SS? Also, why don't we need those calls for the new
> LASS #SS?

do_error_trap() provides catch-all handling for unallowed-thing-happened
exception handling in either kernel or userspace.

We can take simpler path for fatal in-kernel exception. Following #GP
logic matches what we need.

--
Kiryl Shutsemau / Kirill A. Shutemov