From: Steven Rostedt <rostedt@goodmis.org>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>,
open list <linux-kernel@vger.kernel.org>,
Linux trace kernel <linux-trace-kernel@vger.kernel.org>,
lkft-triage@lists.linaro.org,
Stephen Rothwell <sfr@canb.auug.org.au>,
Arnd Bergmann <arnd@arndb.de>,
Dan Carpenter <dan.carpenter@linaro.org>,
Anders Roxell <anders.roxell@linaro.org>
Subject: Re: next-20250605: Test regression: qemu-x86_64-compat mode ltp tracing Oops int3 kernel panic
Date: Thu, 19 Jun 2025 10:00:28 -0400 [thread overview]
Message-ID: <20250619100028.7ec6e40b@batman.local.home> (raw)
In-Reply-To: <20250618084022.db09168befebc193c5b13a6f@kernel.org>
On Wed, 18 Jun 2025 08:40:22 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> > I would add more of what you found above in the change log. And the issue
> > that was triggered I don't think was because of a buffer overflow. It was
> > because an entry was added to the text_poke_array out of order causing the
> > bsearch to fail.
>
> There are two patterns of bugs I saw, one is "Oops: int3" and another is
> "#PF in smp_text_poke_batch_finish (or smp_text_poke_int3_handler)".
> The latter comes from buffer overflow.
>
> -----
> [ 164.164215] BUG: unable to handle page fault for address: ffffffff32c00000
> [ 164.166999] #PF: supervisor read access in kernel mode
> [ 164.169096] #PF: error_code(0x0000) - not-present page
> [ 164.171143] PGD 8364b067 P4D 8364b067 PUD 0
> [ 164.172954] Oops: Oops: 0000 [#1] SMP PTI
> [ 164.174581] CPU: 4 UID: 0 PID: 2702 Comm: sh Tainted: G W 6.15.0-next-20250606-00002-g75b4e49588c2 #239 PREEMPT(voluntary)
> [ 164.179193] Tainted: [W]=WARN
> [ 164.180926] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> [ 164.184696] RIP: 0010:smp_text_poke_batch_finish+0xb9/0x400
> [ 164.186873] Code: e4 4c 8d 6d c2 85 c9 74 39 48 63 03 b9 01 00 00 00 4c 89 ea 41 83 c4 01 48 c7 c7 d0 f7 f7 b2 48 83 c3 10 48 8d b0 00 00 c0 b2 <0f> b6 80 00 00 c0 b2 88 43 ff e8 68 e3 ff ff 44 3b 25 d1 29 5f 02
> -----
>
> This is because smp_text_poke_single() overwrites the
> text_poke_array.vec[TEXT_POKE_ARRAY_MAX], which is nr_entries (and
> the variables next to text_poke_array.)
Interesting. It must be that the stress test was able to get in and add
a bunch of individual entries while a batch was being performed.
Still, both are a bug and solved by the same solution ;-)
(Two for the price of one!)
-- Steve
next prev parent reply other threads:[~2025-06-19 14:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-05 11:42 next-20250605: Test regression: qemu-x86_64-compat mode ltp tracing Oops int3 kernel panic Naresh Kamboju
2025-06-09 13:09 ` Masami Hiramatsu
2025-06-10 8:41 ` Masami Hiramatsu
2025-06-10 13:25 ` Steven Rostedt
2025-06-10 13:20 ` Naresh Kamboju
2025-06-10 14:43 ` Masami Hiramatsu
2025-06-10 14:47 ` [RFC PATCH 1/2] x86: Retry with new instruction if INT3 is disappaered Masami Hiramatsu (Google)
2025-06-10 14:47 ` [RFC PATCH 2/2] x86: alternative: Invalidate the cache for updated instructions Masami Hiramatsu (Google)
2025-06-10 15:50 ` Steven Rostedt
2025-06-11 0:21 ` Masami Hiramatsu
2025-06-11 10:26 ` Masami Hiramatsu
2025-06-11 14:20 ` Steven Rostedt
2025-06-11 15:42 ` Steven Rostedt
2025-06-12 0:04 ` Masami Hiramatsu
2025-06-11 11:30 ` Peter Zijlstra
2025-06-12 0:17 ` Masami Hiramatsu
2025-06-12 16:24 ` Naresh Kamboju
2025-06-13 3:09 ` Masami Hiramatsu
2025-06-10 14:53 ` next-20250605: Test regression: qemu-x86_64-compat mode ltp tracing Oops int3 kernel panic Steven Rostedt
2025-06-12 13:09 ` Naresh Kamboju
2025-06-13 8:27 ` Masami Hiramatsu
2025-06-13 12:01 ` Masami Hiramatsu
2025-06-16 7:36 ` Masami Hiramatsu
2025-06-17 10:41 ` Masami Hiramatsu
2025-06-17 12:10 ` Naresh Kamboju
2025-06-17 12:25 ` Steven Rostedt
2025-06-17 12:31 ` Naresh Kamboju
2025-06-17 14:29 ` Steven Rostedt
2025-06-17 23:40 ` Masami Hiramatsu
2025-06-19 14:00 ` Steven Rostedt [this message]
2025-06-17 16:45 ` Naresh Kamboju
2025-06-17 23:05 ` Masami Hiramatsu
2025-06-17 23:32 ` Steven Rostedt
2025-06-10 0:29 ` Steven Rostedt
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=20250619100028.7ec6e40b@batman.local.home \
--to=rostedt@goodmis.org \
--cc=anders.roxell@linaro.org \
--cc=arnd@arndb.de \
--cc=dan.carpenter@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=lkft-triage@lists.linaro.org \
--cc=mhiramat@kernel.org \
--cc=naresh.kamboju@linaro.org \
--cc=sfr@canb.auug.org.au \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).