From: Nam Cao <namcao@linutronix.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org, Kai Zhang <zhangkai@iscas.ac.cn>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Samuel Holland <samuel.holland@sifive.com>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH stable v6.6] riscv: kprobes: Fix wrong lengths passed to patch_text_nosync()
Date: Tue, 29 Apr 2025 18:48:21 +0200 [thread overview]
Message-ID: <20250429164614.g3w8JJAk@linutronix.de> (raw)
In-Reply-To: <2025042945-financial-rumbling-bcd0@gregkh>
On Tue, Apr 29, 2025 at 06:31:09PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 29, 2025 at 06:14:18PM +0200, Nam Cao wrote:
> > Unlike patch_text(), patch_text_nosync() takes the length in bytes, not
> > number of instructions. It is therefore wrong for arch_prepare_ss_slot() to
> > pass length=1 while patching one instruction.
> >
> > This bug was introduced by commit b1756750a397 ("riscv: kprobes: Use
> > patch_text_nosync() for insn slots"). It has been fixed upstream by commit
> > 51781ce8f448 ("riscv: Pass patch_text() the length in bytes"). However,
> > beside fixing this bug, this commit does many other things, making it
> > unsuitable for backporting.
>
> We would almost always want the original commit, why not just send that
> instead? What is wrong with it being in here as-is?
The original commit is probably fine. But I'm paranoid, because it is not
completely obvious whether the original commit would break something else
in v6.6. Because, as mentioned, it does more than just fixing the bug.
Best regards,
Nam
next prev parent reply other threads:[~2025-04-29 16:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 16:14 [PATCH stable v6.6] riscv: kprobes: Fix wrong lengths passed to patch_text_nosync() Nam Cao
2025-04-29 16:31 ` Greg Kroah-Hartman
2025-04-29 16:48 ` Nam Cao [this message]
2025-04-29 16:51 ` Greg Kroah-Hartman
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=20250429164614.g3w8JJAk@linutronix.de \
--to=namcao@linutronix.de \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=samuel.holland@sifive.com \
--cc=stable@vger.kernel.org \
--cc=zhangkai@iscas.ac.cn \
/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