Thread (36 messages) 36 messages, 5 authors, 2025-09-10

Re: [PATCH v2 05/18] x86/hw_breakpoint: introduce arch_reinstall_hw_breakpoint() for atomic context

From: Jinchao Wang <hidden>
Date: 2025-09-10 09:54:46
Also in: linux-mm, linux-perf-users, lkml

On 9/9/25 16:39, Jinchao Wang wrote:
On 9/9/25 16:00, Masami Hiramatsu (Google) wrote:
quoted
On Mon, 8 Sep 2025 13:20:51 +0800
Jinchao Wang [off-list ref] wrote:
quoted
quoted
...

Yeah, I think not. For one this is an almost verbatim copy of
arch_install_hw_breakpoint() with zero re-use. Surely you've been 
taught
better?
I introduced this to modify bp_addr in atomic context in my RFC series.
I thought it was clearer to split the introduction and refactor.
And then It was used in the wprobe series, so I left it as introduced
in the RFC series.

I agree your suggestion is right. I am willing to refactor after 
wprobe.
I'm OK to refactor it to reuse arch_install_hw_breakpoint().
My point is to have CONFIG_HAVE_REINSTALL_HW_BREAKPOINT so that
we can easily implement the dependency for other features which
requires this feature in Kconfig level.
quoted
quoted
And why would we want to export guts like this?
I wanted to introduce a real-time stack corruption debugging tool,
which needs a helper to change bp_addr in atomic context (kprobe 
handler).
And wprobe needs it also.
I agree with Peter, it should not expose the architecture
dependent code directly. Instead, we need a wrapper.

Thank you,
Understood, I will use the wrapper instead.
Hi Masami,
I would like to ask for your advice regarding a development workflow issue.

I have a patch series that refactors |arch_reinstall_hw_breakpoint|, which
I know you are using in your |wprobe| series. My new feature, 
|kstackwatch|, is
dependent on my patches and also on your wrapper patch for 
|modify_wide_hw_breakpoint_local|.

Since we are working on different subsystems with different maintainers,
I am concerned about how to handle the dependencies between our patches 
to avoid
introducing trouble.

What is the best practice for this type of cross-subsystem dependency?
Should one of us carry all the patches until they are merged, or is there a
standard procedure for this situation?

Thank you for your guidance.

-- 
Thanks,
Jinchao
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help