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.gnugeneration.com/ (local)

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