On 2021/02/11 1:46, Steven Rostedt wrote: > On Thu, 11 Feb 2021 01:39:41 +0900 > Tetsuo Handa <[email protected]> wrote: > >> On 2021/02/11 1:18, Steven Rostedt wrote: >>> The point of this exercise is to be able to debug the *same* kernel that >>> someone is having issues with. And this is to facilitate that debugging. >> >> That's too difficult to use. If a problem is not reproducible, we will have >> no choice but always specify "never hash pointers" command line option. If a >> problem is reproducible, we can rebuild that kernel with "never hash >> pointers" >> config option turned on. > > Now the question is, why do you need the unhashed pointer?
Because unhashed pointers might give some clue. We can rebuild the same kernel using the same kernel config / compiler etc. and compare unhashed pointers with addresses in System.map / kallsyms files without reproducing the problem. > > Currently, the instruction pointer is what is fine right? You get the > a function and its offset. If there's something that is needed, perhaps we > should look at how to fix that, instead of just unhashing all pointers by > default. I'm not refusing to use kernel command line options. I'm expecting that we can also hardcode using kernel config options. Since boot-time switching via kernel command line options makes the kernel behave differently, less boot-time switching is better for avoiding unexpected problems (e.g. unintended LSM was enabled).
