All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Scheiner <frank.scheiner@web.de>
To: linux-ia64@vger.kernel.org
Subject: Re: Boot regression in Linux v6.4-rc3
Date: Sat, 27 May 2023 18:34:50 +0000	[thread overview]
Message-ID: <b2b47c19-d527-fbd2-1666-801f173b6174@web.de> (raw)
In-Reply-To: <abb1166d-27a9-fbae-59cd-841480fba78a@web.de>

Hi,

On 27.05.23 19:08, Linus Torvalds wrote:
> Anyway, the WARN_ON() is likely related, but the bug is clearly an
> unexpected page fault in __copy_user() when called by load_module().
>
> The ia64 oops output is nasty, presumably because ia64 aggressively
> inlines things. It would help a lot if you enabled debug info (maybe
> you already do?)

I believe it is enabled - I have at least CONFIG_DEBUG_KERNEL=y and
CONFIG_DEBUG_INFO=y - my kernel config is on [1] for reference.

[1]: https://pastebin.com/HRQtZ9vb

> and then run the oops through
> ./scripts/decode_stacktrace.sh which will figure out line numbers,
> inlining etc.
>
> Because I don't even see why it would call __copy_user() in the first
> place. This is 'finit_module()' that loads the module data from a
> file, not user space.
>
> So I guess it must be the strndup_user() in
>
>          mod->args = strndup_user(uargs, ~0UL >> 1);
>
> but that doesn't look like it should even care about any module
> layout. Plus I would have expected to see strndup_user() in the call
> trace, but whatever.
>
> End result: that ia64 trace is very hard to read, and _maybe_ running
> it through the decode script might give more information about what it
> is that triggers...

Ok, I put the decoded console messages on [2].

[2]: https://pastebin.com/dLYMijfS

Cheers,
Frank

  parent reply	other threads:[~2023-05-27 18:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-26 10:55 Boot regression in Linux v6.4-rc3 Frank Scheiner
2023-05-26 16:49 ` Song Liu
2023-05-26 18:30 ` Frank Scheiner
2023-05-26 21:01 ` Song Liu
2023-05-26 21:59 ` Luis Chamberlain
2023-05-26 22:22 ` Linus Torvalds
2023-05-26 22:39 ` Song Liu
2023-05-27  6:26 ` Frank Scheiner
2023-05-27  7:01 ` Frank Scheiner
2023-05-27 17:08 ` Linus Torvalds
2023-05-27 18:34 ` Frank Scheiner [this message]
2023-05-27 19:34 ` Linus Torvalds
2023-05-27 21:13 ` Frank Scheiner
2023-05-28  5:24 ` Song Liu
2023-05-28  7:30 ` Frank Scheiner
2023-05-28  8:09 ` Frank Scheiner
2023-05-28 10:13 ` John Paul Adrian Glaubitz
2023-05-28 22:46 ` Song Liu
2023-05-30 20:21 ` Konstantin Ryabitsev
2023-05-30 21:04 ` Linus Torvalds
2023-05-30 21:04   ` Linus Torvalds
2023-05-30 21:11 ` Konstantin Ryabitsev
2023-05-30 21:11   ` Konstantin Ryabitsev
2023-05-31 18:15 Frank Scheiner

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=b2b47c19-d527-fbd2-1666-801f173b6174@web.de \
    --to=frank.scheiner@web.de \
    --cc=linux-ia64@vger.kernel.org \
    /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.