Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx> writes:
> On (05/09/19 21:47), Linus Torvalds wrote:
>> [ Sorry about html and mobile crud, I'm not at the computer right now ]
>> How about we just undo the whole misguided probe_kernel_address() thing?
>
> But the problem will remain - %pS/%pF on PPC (and some other arch-s)
> do dereference_function_descriptor(), which calls probe_kernel_address().
(Only on 64-bit big endian, and we may even change that one day)
> So if probe_kernel_address() starts to dump_stack(), then we are heading
> towards stack overflow. Unless I'm totally missing something.
We only ended up calling dump_stack() from probe_kernel_address() due to
a combination of things:
1. probe_kernel_address() actually uses __copy_from_user_inatomic()
which is silly because it's not doing a user access.
2. our user access code uses mmu_has_feature() which uses jump labels,
and so isn't safe to call until we've initialised those jump labels.
This is unnecessarily fragile, we can easily make the user access
code safe to call before the jump labels are initialised.
3. we had extra debug code enabled in mmu_has_feature() which calls
dump_stack().
I've fixed 2, and plan to fix 1 as well at some point. And 3 is behind a
CONFIG option that no one except me is going to have enabled in
practice.
So in future we shouldn't be calling dump_stack() in that path.
cheers
