RE: CONFIG_ORC_UNWINDER=y breaks get_wchan()?

[David Laight]

From: Jann Horn
> Sent: 24 September 2021 01:00
...
> > Normally wchan is protected by:
> >
> >         ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS)
> >
> > I might argue that this check isn't right -- it needs to be using
> > f_cred, but I'll let Jann answer more there.
> >
> > > ... since presumably proc_pid_wchan()'s use of '%ps' can result in an
> > > actual address getting printed if the unwind gets confused, thanks to
> > > __sprint_symbol()'s backup option if kallsyms_lookup_buildid() doesn't
> > > find a name.
> >
> > Ew, yeah, __sprint_symbol() falls back to exposing addresses. :(
> >
> >         name = kallsyms_lookup_buildid(address, &size, &offset, &modname, &buildid,
> >                                        buffer);
> >         if (!name)
> >                 return sprintf(buffer, "0x%lx", address - symbol_offset);
> 
> Whaaaat? That's not how wchan worked when I looked at this the last
> time a few years ago...

Hmmmm....
Historically (and I mean SYSV and probably BSD) the 'wchan'
was the 'token' passed to the kernel sleep() function and
value that needed to be passed to wakeup() to get the process
rescheduled.
It was usually the address of something associated with the
sleep - but didn't have to be.
Linux doesn't do process sleep/wakeup the same way.

The nearest thing would be 'struct wait_queue_head'.
But the address of that isn't a useful value.
Plausibly the address of the function that initialises
the wait_queue_head could be put into it and that
value saved by schedule() to that it can be returned
as the 'wchan'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)