Hi, This attempts to solve the issues from the discussion here[1]. Specifically: 1) wchan has been broken under ORC, seen as a failure to stack walk resulting in _usually_ a 0 value, since ee9f8fce9964 (v4.14). 2) wchan leaking raw addresses since 152c432b128c (v5.12). Based on what I can see in the stack walking code, the fix should be safe. Jann may have more thoughts, but from what I can see, the walker pins the stack, decodes only a single step, etc. I'd like Josh's review of Qi Zheng's patch, though. :) It's also not clear to me what impact this had on kernel/sched/fair.c: it would have also been seeing 0s, so this may be fixing a bug there too. Thanks! -Kees [1] https://lore.kernel.org/lkml/20210924054647.v6x6risoa4jhuu6s@xxxxxxxxxxxxxxxxxxxxxxxx/ Kees Cook (2): Revert "proc/wchan: use printk format instead of lookup_symbol_name()" leaking_addresses: Always print a trailing newline Qi Zheng (1): x86: Fix get_wchan() to support the ORC unwinder arch/x86/kernel/process.c | 51 +++--------------------------------- fs/proc/base.c | 19 ++++++++------ scripts/leaking_addresses.pl | 3 ++- 3 files changed, 16 insertions(+), 57 deletions(-) -- 2.30.2
