Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 15 Jun 2020 15:23:24 -0700 | Subject | Re: Linux 5.8-rc1 BUG unable to handle page fault (snd_pcm) |
| |
On Mon, Jun 15, 2020 at 2:18 PM Shuah Khan <skhan@linuxfoundation.org> wrote: > > Yeah. I should have thought about adding module path. With module path > added, I get better results: > > [ 15.341267] ? snd_pcm_hw_params (./include/linux/string.h:391 > /home/shuah/lkml/linux_5.8/sound/core/pcm_native.c:759) snd_pcm > [ 15.341272] snd_pcm_common_ioctl (sound/core/pcm_native.c:792 > /home/shuah/lkml/linux_5.8/sound/core/pcm_native.c:3210) snd_pcm
Yeah, now it gives the complete path and you see exactly which memset() it ends up being, ie it's that
/* clear the buffer for avoiding possible kernel info leaks */ if (runtime->dma_area && !substream->ops->copy_user) memset(runtime->dma_area, 0, runtime->dma_bytes);
Quite often with all the inlining the compiler does it can be really hard to figure out where things come from when you just see the symbol and offset.
Ok, in this case there aren't that many calls to memset() in that file, and it might have been obvious which one it was in this case. But sometimes they just come from various inline helper functions too, and when automation can give us the answer easily, it's the thing to do.
> > Maybe even just a warning about lacking a module path when there are > > module symbols present? > > > > It does tell you the usage.
Yes, it's more that it's very easy to overlook it, and then get a partial decode.
Once you know how to use that script, it's very convenient, but the problem tends to be that too few people are aware of it in the first place.
Linus
| |