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

[Jinchao Wang <wangjinchao600@gmail.com>]

On 9/9/25 16:39, Jinchao Wang wrote:
>
> On 9/9/25 16:00, Masami Hiramatsu (Google) wrote:
>> On Mon, 8 Sep 2025 13:20:51 +0800
>> Jinchao Wang <wangjinchao600@gmail.com> wrote:
>>>> ...
>>>>
>>>> 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.
>>
>>>> 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