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@shells.gnugener...
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(-)