<div dir="auto"><div dir="auto">[ Sorry about html and mobile crud, I'm not at the computer right now ]</div><div dir="auto"><br></div>How about we just undo the whole misguided probe_kernel_address() thing?<div dir="auto"><br></div><div dir="auto">The excuse for is was that it would avoid crashes.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">So let's admit that and just go back to the old sane model.</div><div dir="auto"><br></div><div dir="auto">Seriously, we've never needed that odd probing. It causes issues. It's wrong and pointless.</div><div dir="auto"><br></div><div dir="auto">       Linus</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 9, 2019, 21:32 Sergey Senozhatsky <<a href="mailto:sergey.senozhatsky.work@gmail.com">sergey.senozhatsky.work@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On (05/09/19 14:19), Petr Mladek wrote:<br>
> 1. Report on Power:<br>
> <br>
> Kernel crashes very early during boot with with CONFIG_PPC_KUAP and<br>
> CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG<br>
> <br>
> The problem is the combination of some new code called via printk(),<br>
> check_pointer() which calls probe_kernel_read(). That then calls<br>
> allow_user_access() (PPC_KUAP) and that uses mmu_has_feature() too early<br>
> (before we've patched features). With the JUMP_LABEL debug enabled that<br>
> causes us to call printk() & dump_stack() and we end up recursing and<br>
> overflowing the stack.<br>
<br>
Hmm... hmm... PPC does an .opd-based symbol dereference, which<br>
eventually probe_kernel_read()-s. So early printk(%pS) will do<br>
<br>
        printk(%pS)<br>
         dereference_function_descriptor()<br>
          probe_kernel_address()<br>
           dump_stack()<br>
            printk(%pS)<br>
             dereference_function_descriptor()<br>
              probe_kernel_address()<br>
               dump_stack()<br>
                printk(%pS)<br>
                 ...<br>
<br>
I'd say... that it's not vsprintf that we want to fix, it's<br>
the idea that probe_kernel_address() can dump_stack() on any<br>
platform. On some archs probe_kernel_address()->dump_stack()<br>
is going nowhere:<br>
 dump_stack() does probe_kernel_address(), which calls dump_stack(),<br>
 which calls printk(%pS)->probe_kernel_address() again and again,<br>
 and again.<br>
<br>
        -ss<br>
</blockquote></div>