All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: YiFei Zhu <zhuyifei1999@gmail.com>,
	Colin Ian King <colin.king@canonical.com>
Cc: linux-um@lists.infradead.org, Jeff Dike <jdike@addtoit.com>,
	Richard Weinberger <richard@nod.at>,
	Anton Ivanov <anton.ivanov@cambridgegreys.com>,
	Benjamin Berg <benjamin@sipsolutions.net>
Subject: Re: [PATCH v2] um: Fix stack pointer alignment
Date: Tue, 20 Apr 2021 08:51:17 +0200	[thread overview]
Message-ID: <4f6922f1739dc675d50130a3c07bf28a2bc6f380.camel@sipsolutions.net> (raw)
In-Reply-To: <CABqSeAQdwhJCTyO9w6f2cmyobh2bnA5wG6ZgCS9gD0b7ZSi=yw@mail.gmail.com> (sfid-20210420_074740_851869_49DF5D49)

> 
> It seems config related. I tested with my original config and it
> segfault loops, but then I tested with a fresh defconfig, then enabled
> RTC_CLASS and UML_RTC and it boots successfully, with the assembly as:
> 
>   movaps (%rdx),%xmm0
>   movaps %xmm0,(%r12)
> 
> The move from xmm0 to stack is omitted.
> 
> After a bit of trial and error I found changing from
> CC_OPTIMIZE_FOR_SIZE to CC_OPTIMIZE_FOR_PERFORMANCE alone makes the
> difference. What's also interesting is that instead of
> segfault-looping (as in, segfault recovery did not do anything to fix
> the fault, so after sigreturn it segfaults again), it panics with
> "Segfault with no mm" which seems more like the expected behavior.

Aha, interesting.

> 
> I'll send a v3 to clarify CC_OPTIMIZE_FOR_PERFORMANCE.

Cool, thanks for all the digging and fixes!

johannes


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

  parent reply	other threads:[~2021-04-20  6:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-19 15:32 [PATCH v2] um: Fix stack pointer alignment YiFei Zhu
2021-04-19 19:41 ` Johannes Berg
2021-04-19 20:36   ` YiFei Zhu
2021-04-20  5:47     ` YiFei Zhu
2021-04-20  6:20       ` YiFei Zhu
2021-04-20  6:51       ` Johannes Berg [this message]
2021-04-20  6:50     ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f6922f1739dc675d50130a3c07bf28a2bc6f380.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=benjamin@sipsolutions.net \
    --cc=colin.king@canonical.com \
    --cc=jdike@addtoit.com \
    --cc=linux-um@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=zhuyifei1999@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.