UML kernel panic on initialization

[Johannes Berg]

On Tue, 2021-07-13 at 21:22 +0200, Johannes Berg wrote:
> On Sat, 2021-07-10 at 15:00 -0600, subashab at codeaurora.org wrote:
> > 
> > I have reverted the following patches (to allow for a clean revert)
> > and I don't see the panic anymore -
> > 
> > bfc58e2b98e99737409cd9f4d86a79677c5b887c
> > dc01a3b9db43abf95b801c9694980777a329e303
> > 9f0b4807a44ff81cf59421c8a86641efec586610
> > 84b2789d61156db0224724806b20110c0d34b07c
> 
> Out of those 4, the last ("separate child and...") seems actually less
> intrusive than the previous one. If you revert only the first three of
> this list, does it still happen?
> 
> Does it still happen if you unset CONFIG_CC_OPTIMIZE_FOR_SIZE and do
> CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE instead?

Oh, and it looks like 84b2789d6115 actually got some bits that shouldn't
have been there!

Assuming it does *not* work with just the first three patches reverted,
does it work again if you revert the first three patches, and only this
bit of the fourth?

--- a/arch/um/kernel/skas/clone.c
+++ b/arch/um/kernel/skas/clone.c
@@ -24,29 +24,26 @@
 void __attribute__ ((__section__ (".__syscall_stub")))
 stub_clone_handler(void)
 {
-       struct stub_data *data = (struct stub_data *) STUB_DATA;
+       int stack;
+       struct stub_data *data = (void *) ((unsigned long)&stack & ~(UM_KERN_PAGE_SIZE - 1));
        long err;



I think we probably have some miscompilation again with this thing - I
saw a bunch of similar issues with our syscall stubs at some point, and
I'm not sure we got it all right already.

johannes