[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHVXubjdpFER1v54dAD-Bg=Ya4NkDxn=v+9bug0Xng2Ta=Nz8Q@mail.gmail.com>
Date: Tue, 20 Feb 2024 23:11:54 +0100
From: Alexandre Ghiti <alexghiti@...osinc.com>
To: Björn Töpel <bjorn@...nel.org>
Cc: Andrea Parri <parri.andrea@...il.com>, Samuel Holland <samuel.holland@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, Jason Baron <jbaron@...mai.com>,
Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>, bpf@...r.kernel.org,
Björn Töpel <bjorn@...osinc.com>
Subject: Re: [PATCH 0/7] riscv: Various text patching improvements
On Mon, Feb 19, 2024 at 1:25 PM Björn Töpel <bjorn@...nelorg> wrote:
>
> Andrea Parri <parri.andrea@...il.com> writes:
>
> > Hi Samuel,
> >
> > On Sun, Feb 11, 2024 at 06:55:11PM -0800, Samuel Holland wrote:
> >> Here are a few changes to minimize calls to stop_machine() and
> >> flush_icache_*() in the various text patching functions, as well as
> >> to simplify the code.
> >>
> >>
> >> Samuel Holland (7):
> >> riscv: jump_label: Batch icache maintenance
> >> riscv: jump_label: Simplify assembly syntax
> >> riscv: kprobes: Use patch_text_nosync() for insn slots
> >> riscv: Simplify text patching loops
> >> riscv: Pass patch_text() the length in bytes
> >> riscv: Use offset_in_page() in text patching functions
> >> riscv: Remove extra variable in patch_text_nosync()
> >
> > This does look like a nice clean-up. Just curious (a "teach me"-like question),
> > how did you test these changes? kselftests, micro-benchmarks, other?
> >
> > BTW, I recall a parallel work from Alex and Bjorn [1] that might have some minor
> > conflict with these changes; + both of them to Cc: for further sync.
>
> Indeed! I think Alex is still working on the v2.
Actually I was blocked by Andrea's comment about patch_map(), but it's
not related so I can spin another version soon. I'd say mine should
land first because AIA support may get into 6.9 (?) and then this
patch would be needed. In case you re-spin another version, can you
rebase on top of it? Unless you have another solution of course.
Thanks,
Alex
Powered by blists - more mailing lists