On 2024/3/5 1:40, Kees Cook wrote: > On Mon, Mar 04, 2024 at 04:15:07PM +0100, Jann Horn wrote: >> On Mon, Mar 4, 2024 at 3:02 AM Jiangfeng Xiao <xiaojiangfeng@xxxxxxxxxx> wrote: >>> When the last instruction of a noreturn function is a call >>> to another function, the return address falls outside >>> of the function boundary. This seems to cause kernel >>> to interrupt the backtrace. > > FWIW, all email from huawei.com continues to get eaten by anti-spam > checking. I've reported this a few times -- it'd be really nice if the > domain configuration could get fixed. > >> [...] >>> Delete __noreturn from usercopy_abort, >> >> This sounds like the actual bug is in the backtracing logic? I don't >> think removing __noreturn annotations from an individual function is a >> good fix, since the same thing can happen with other __noreturn >> functions depending on what choices the compiler makes. > > Yeah, NAK. usercopy_abort() doesn't return. It ends with BUG(). > When the user directly or indirectly calls usercopy_abort, the final call stack is incorrect, and the code where the problem occurs cannot be located. In this case, the user will be frustrated. For the usercopy_abort function, whether '__noreturn' is added does not affect the internal behavior of the usercopy_abort function. Therefore, it is recommended that '__noreturn' be deleted so that backtrace can work properly.
