[ 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?
The excuse for is was that it would avoid crashes.
It turns out that was wrong, and that it just made things much worse.
Honestly, we haven't really had the crashes that the logic was supposed to
protect against in the first place, so by now it's clear that the whole
thing was a stupid and horrible mistake in the first place.
So let's admit that and just go back to the old sane model.
Seriously, we've never needed that odd probing. It causes issues. It's
wrong and pointless.
Linus
On Thu, May 9, 2019, 21:32 Sergey Senozhatsky <
sergey.senozhatsky.work@gmail.com> wrote:
On (05/09/19 14:19), Petr Mladek wrote:
quoted
1. Report on Power:
Kernel crashes very early during boot with with CONFIG_PPC_KUAP and
CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
The problem is the combination of some new code called via printk(),
check_pointer() which calls probe_kernel_read(). That then calls
allow_user_access() (PPC_KUAP) and that uses mmu_has_feature() too early
(before we've patched features). With the JUMP_LABEL debug enabled that
causes us to call printk() & dump_stack() and we end up recursing and
overflowing the stack.
Hmm... hmm... PPC does an .opd-based symbol dereference, which
eventually probe_kernel_read()-s. So early printk(%pS) will do
printk(%pS)
dereference_function_descriptor()
probe_kernel_address()
dump_stack()
printk(%pS)
dereference_function_descriptor()
probe_kernel_address()
dump_stack()
printk(%pS)
...
I'd say... that it's not vsprintf that we want to fix, it's
the idea that probe_kernel_address() can dump_stack() on any
platform. On some archs probe_kernel_address()->dump_stack()
is going nowhere:
dump_stack() does probe_kernel_address(), which calls dump_stack(),
which calls printk(%pS)->probe_kernel_address() again and again,
and again.
-ss