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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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().

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?

I apologize if the questions seem too naive. I am finding the exception
handling code a bit convoluted to understand. In general, I would
suggest adding some code comments at least for the new code to help
ignorant folks like me looking at this in the future.




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux