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
