linux-kernel - Re: [PATCH v2 05/18] x86/hw_breakpoint: introduce arch_reinstall_hw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e82bc49b-a1fe-419a-8a5e-fda70603d2e3@gmail.com>
Date: Wed, 10 Sep 2025 17:54:33 +0800
From: Jinchao Wang <wangjinchao600@...il.com>
To: "Masami Hiramatsu (Google)" <mhiramat@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
 Andrew Morton <akpm@...ux-foundation.org>, "Naveen N . Rao"
 <naveen@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, Arnaldo Carvalho de Melo
 <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
 Mark Rutland <mark.rutland@....com>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
 Adrian Hunter <adrian.hunter@...el.com>,
 "Liang, Kan" <kan.liang@...ux.intel.com>,
 David Hildenbrand <david@...hat.com>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>, Vlastimil Babka
 <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
 Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
 linux-perf-users@...r.kernel.org, linux-mm@...ck.org,
 linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 05/18] x86/hw_breakpoint: introduce
 arch_reinstall_hw_breakpoint() for atomic context

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@...il.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