关于ARM64架构Linux内核kernel_entry宏的两个技术疑问：内核态下addr_limit设为USER_DS的原因与栈回溯中pt_regs内fp、elr的作用

Q1: 内核态异常时，为何要将task_struct.thread_info.addr_limit设置为USER_DS？ #

这个操作绝对不是切换到用户态，而是内核为了安全和一致性做出的设计，核心原因有两点：

1. 强制安全检查：内核里很多内存访问辅助函数（比如copy_from_user、get_user）会通过addr_limit判断是否需要做严格的权限验证。当内核处理自身异常时（比如内核代码触发页错误、指令异常），如果保留默认的KERNEL_DS（允许访问整个虚拟地址空间），这些函数会跳过权限检查直接访问内存。设置成USER_DS后，会强制这些函数执行和用户态调用时一样的安全校验，避免内核因特权身份绕过验证而访问无效或非法内存。
2. 异常场景兼容性：如果异常是在处理用户态系统调用的内核路径中触发的，内核需要访问用户空间内存来收集异常上下文。将addr_limit设为USER_DS能确保这种访问遵循用户态页表权限，符合内核内存访问的安全模型，防止越权访问。

另外代码里先把原addr_limit值保存到pt_regs的S_ORIG_ADDR_LIMIT字段，异常处理完成后会恢复这个值，不会影响后续内核流程。

Q2: 不同特权级异常时，S_STACKFRAME的存储内容为何不同？ #

这完全是为了栈回溯的正确性和安全性，分两种场景说明：

场景1：异常来自同一特权级（EL1/EL2，内核态自身异常）

内核的栈回溯依赖于栈帧链：每个内核函数的栈帧底部会保存前一个栈帧的指针（fp/x29）和当前函数的返回地址（lr/x30），回溯代码通过遍历这个链还原调用路径。但异常发生时，CPU会自动把lr设为异常返回地址，覆盖了原函数的返回地址，同时当前栈帧可能还没完全初始化。

这时把异常发生前的fp/x29（原栈帧指针）和elr_el1（异常发生时的指令地址，相当于原函数执行到的位置）存入S_STACKFRAME，相当于手动在pt_regs里构建了一个“伪栈帧”，让回溯代码能通过这个字段衔接上异常前的内核栈帧链，完整还原异常发生时的调用路径。

场景2：异常来自EL0（用户态到内核态）

用户态栈帧在用户虚拟地址空间，内核直接访问这些地址不仅需要特殊权限检查，而且用户态的栈回溯规则（栈帧结构、返回地址存储方式）和内核完全不同。更关键的是，用户态指针属于用户空间地址，内核态直接用这些指针回溯可能触发页错误或安全问题。

因此这里把S_STACKFRAME设为零（xzr），明确告诉回溯代码：这里没有有效的内核栈帧链，不要尝试从这里回溯用户态路径（用户态栈回溯会通过pt_regs中保存的用户寄存器单独处理）。

内容的提问来源于stack exchange，提问作者Chan Kim