linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jinchao Wang <wangjinchao600@gmail.com>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Naveen N . Rao" <naveen@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	David Hildenbrand <david@redhat.com>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	linux-perf-users@vger.kernel.org, linux-mm@kvack.org,
	linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 05/18] x86/hw_breakpoint: introduce arch_reinstall_hw_breakpoint() for atomic context
Date: Tue, 9 Sep 2025 16:39:15 +0800	[thread overview]
Message-ID: <f73e6e8c-282e-4d3d-9dc9-49f13b20a255@gmail.com> (raw)
In-Reply-To: <20250909170017.dae27d8be77f9ec634e0d56c@kernel.org>


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:
>
>> On Thu, Sep 04, 2025 at 08:38:32AM +0200, Peter Zijlstra wrote:
>>> On Thu, Sep 04, 2025 at 08:21:02AM +0800, Jinchao Wang wrote:
>>>> Introduce arch_reinstall_hw_breakpoint() to update hardware breakpoint
>>>> parameters (address, length, type) without freeing and reallocating the
>>>> debug register slot.
>>>>
>>>> This allows atomic updates in contexts where memory allocation is not
>>>> permitted, such as kprobe handlers.
>>>>
>>>> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
>>>> ---
>>>>   arch/x86/include/asm/hw_breakpoint.h |  1 +
>>>>   arch/x86/kernel/hw_breakpoint.c      | 50 ++++++++++++++++++++++++++++
>>>>   2 files changed, 51 insertions(+)
>>>>
>>>> diff --git a/arch/x86/include/asm/hw_breakpoint.h b/arch/x86/include/asm/hw_breakpoint.h
>>>> index 0bc931cd0698..bb7c70ad22fe 100644
>>>> --- a/arch/x86/include/asm/hw_breakpoint.h
>>>> +++ b/arch/x86/include/asm/hw_breakpoint.h
>>>> @@ -59,6 +59,7 @@ extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
>>>>   
>>>>   
>>>>   int arch_install_hw_breakpoint(struct perf_event *bp);
>>>> +int arch_reinstall_hw_breakpoint(struct perf_event *bp);
>>>>   void arch_uninstall_hw_breakpoint(struct perf_event *bp);
>>>>   void hw_breakpoint_pmu_read(struct perf_event *bp);
>>>>   void hw_breakpoint_pmu_unthrottle(struct perf_event *bp);
>>>> diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
>>>> index b01644c949b2..89135229ed21 100644
>>>> --- a/arch/x86/kernel/hw_breakpoint.c
>>>> +++ b/arch/x86/kernel/hw_breakpoint.c
>>>> @@ -132,6 +132,56 @@ int arch_install_hw_breakpoint(struct perf_event *bp)
>>>>   	return 0;
>>>>   }
>>>>   
>>>> +/*
>>>> + * Reinstall a hardware breakpoint on the current CPU.
>>>> + *
>>>> + * This function is used to re-establish a perf counter hardware breakpoint.
>>>> + * It finds the debug address register slot previously allocated for the
>>>> + * breakpoint and re-enables it by writing the address to the debug register
>>>> + * and setting the corresponding bits in the debug control register (DR7).
>>>> + *
>>>> + * It is expected that the breakpoint's event context lock is already held
>>>> + * and interrupts are disabled, ensuring atomicity and safety from other
>>>> + * event handlers.
>>>> + */
>>>> +int arch_reinstall_hw_breakpoint(struct perf_event *bp)
>>>> +{
>>>> +	struct arch_hw_breakpoint *info = counter_arch_bp(bp);
>>>> +	unsigned long *dr7;
>>>> +	int i;
>>>> +
>>>> +	lockdep_assert_irqs_disabled();
>>>> +
>>>> +	for (i = 0; i < HBP_NUM; i++) {
>>>> +		struct perf_event **slot = this_cpu_ptr(&bp_per_reg[i]);
>>>> +
>>>> +		if (*slot == bp)
>>>> +			break;
>>>> +	}
>>>> +
>>>> +	if (WARN_ONCE(i == HBP_NUM, "Can't find a matching breakpoint slot"))
>>>> +		return -EINVAL;
>>>> +
>>>> +	set_debugreg(info->address, i);
>>>> +	__this_cpu_write(cpu_debugreg[i], info->address);
>>>> +
>>>> +	dr7 = this_cpu_ptr(&cpu_dr7);
>>>> +	*dr7 |= encode_dr7(i, info->len, info->type);
>>>> +
>>>> +	/*
>>>> +	 * Ensure we first write cpu_dr7 before we set the DR7 register.
>>>> +	 * This ensures an NMI never see cpu_dr7 0 when DR7 is not.
>>>> +	 */
>>>> +	barrier();
>>>> +
>>>> +	set_debugreg(*dr7, 7);
>>>> +	if (info->mask)
>>>> +		amd_set_dr_addr_mask(info->mask, i);
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(arch_reinstall_hw_breakpoint);
>>> 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.



  reply	other threads:[~2025-09-09  8:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-04  0:20 [PATCH v2 00/18] mm/ksw: Introduce real-time Kernel Stack Watch debugging tool Jinchao Wang
2025-09-04  0:20 ` [PATCH v2 01/18] mm/ksw: add build system support Jinchao Wang
2025-09-04  7:46   ` Mike Rapoport
2025-09-08  5:48     ` Jinchao Wang
2025-09-04  0:20 ` [PATCH v2 02/18] mm/ksw: add ksw_config struct and parser Jinchao Wang
2025-09-04  7:47   ` Mike Rapoport
2025-09-08  5:58     ` Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 03/18] mm/ksw: add /proc/kstackwatch interface Jinchao Wang
2025-09-04  7:51   ` Mike Rapoport
2025-09-08  6:03     ` Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 04/18] mm/ksw: add HWBP pre-allocation support Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 05/18] x86/hw_breakpoint: introduce arch_reinstall_hw_breakpoint() for atomic context Jinchao Wang
2025-09-04  6:38   ` Peter Zijlstra
2025-09-08  5:20     ` Jinchao Wang
2025-09-09  8:00       ` Masami Hiramatsu
2025-09-09  8:39         ` Jinchao Wang [this message]
2025-09-10  9:54           ` Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 06/18] perf/hw_breakpoint: add arch-independent hw_breakpoint_modify_local() Jinchao Wang
2025-09-04  6:44   ` Peter Zijlstra
2025-09-08  5:36     ` Jinchao Wang
2025-09-05 16:18   ` kernel test robot
2025-09-05 17:31   ` kernel test robot
2025-09-04  0:21 ` [PATCH v2 07/18] mm/ksw: add atomic watch on/off operations Jinchao Wang
2025-09-04  6:46   ` Peter Zijlstra
2025-09-08  5:23     ` Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 08/18] mm/ksw: add stack probe support Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 09/18] mm/ksw: implement stack canary and local var resolution logic Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 10/18] mm/ksw: add per-task recursion depth tracking Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 11/18] mm/ksw: coordinate watch and stack for full functionality Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 12/18] mm/ksw: add self-debug functions for kstackwatch watch Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 13/18] mm/ksw: add test module Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 14/18] mm/ksw: add stack overflow test Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 15/18] mm/ksw: add simplified silent corruption test Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 16/18] mm/ksw: add recursive " Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 17/18] tools/kstackwatch: add interactive test script for KStackWatch Jinchao Wang
2025-09-04  0:21 ` [PATCH v2 18/18] MAINTAINERS: add entry for KStackWatch (Kernel Stack Watch) Jinchao Wang

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=f73e6e8c-282e-4d3d-9dc9-49f13b20a255@gmail.com \
    --to=wangjinchao600@gmail.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=hpa@zytor.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mark.rutland@arm.com \
    --cc=mhiramat@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=naveen@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=x86@kernel.org \
    /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