From: Jinchao Wang <wangjinchao600@gmail.com>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: akpm@linux-foundation.org, naveen@kernel.org,
davem@davemloft.net, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 02/13] x86/HWBP: Add arch_reinstall_hw_breakpoint() for atomic updates
Date: Mon, 1 Sep 2025 18:23:44 +0800 [thread overview]
Message-ID: <284d5eef-447f-4e12-a121-3742d708c96f@gmail.com> (raw)
In-Reply-To: <20250901160602.e25f0107e7b0ef4af1078fb7@kernel.org>
On 9/1/25 15:06, Masami Hiramatsu (Google) wrote:
> Hi Jinchao,
>
Hi Masami,
> On Mon, 18 Aug 2025 20:26:07 +0800
> Jinchao Wang <wangjinchao600@gmail.com> wrote:
>
>> Add arch_reinstall_hw_breakpoint() to enable atomic context modification
>> of hardware breakpoint parameters without deallocating and reallocating
>> the breakpoint slot.
>>
>> The existing arch_install_hw_breakpoint() allocates a new debug register
>> slot, while arch_uninstall_hw_breakpoint() deallocates it. However, some
>> use cases require modifying breakpoint parameters (address, length, type)
>> atomically without losing the allocated slot, particularly when operating
>> in atomic contexts where allocation might fail or be unavailable.
>>
>> This is particularly useful for debugging tools like kstackwatch that
>> need to dynamically update breakpoint targets in atomic contexts while
>> maintaining consistent hardware state.
>>
>
> I'm also trying to find this interface for my wprobe. So the idea is good.
> But this looks hacky and only for x86. I think the interface should be
> more generic and do not use this arch internal function directly.
>
I agree with your point about the architectural dependency. I have been
considering this problem not only for the hardware breakpoint
reinstallation,
but also for other related parts of the series, such as canary finding and
stack address resolving. These parts also rely on arch-specific code.
> It seems that the slot is allocated by "type", thus, if this reinstall
> hwbp without deallocate/allocate slot, it must NOT change the type.
> See __modify_bp_slot. Also, provide CONFIG_HAVE_... option for checking
> whether the architecture support that interface.
>
Regarding the slot allocation, I would like to clarify my point. I
believe the
event->attr.type should not be changed when reinstalling a hardware
breakpoint, as this defines the fundamental nature of the event. The type
must always be PERF_TYPE_BREAKPOINT.
The event->attr.bp_type, however, can be changed. For example, from a
HW_BREAKPOINT_W to a HW_BREAKPOINT_RW without needing to deallocate and
reallocate the slot. This is useful for future applications, even though the
current use case for KStackWatch only requires HW_BREAKPOINT_W.
By the way, I have sent an updated series.
https://lore.kernel.org/all/20250828073311.1116593-1-wangjinchao600@gmail.com/
Thank you again for your valuable review.
--
Best regards,
Jinchao
next prev parent reply other threads:[~2025-09-01 10:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 12:26 [RFC PATCH 00/13] mm: Introduce Kernel Stack Watch debugging tool Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 01/13] mm: Add kstackwatch build infrastructure Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 02/13] x86/HWBP: Add arch_reinstall_hw_breakpoint() for atomic updates Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 03/13] mm/kstackwatch: Add module core and configuration interface Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 04/13] mm/kstackwatch: Add HWBP pre-allocation infrastructure Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 05/13] mm/kstackwatch: Add atomic HWBP arm/disarm operations Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 06/13] mm/kstackwatch: Add stack address resolution functions Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 07/13] mm/kstackwatch: Add kprobe and stack watch control Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 08/13] mm/kstackwatch: Wire up watch and stack subsystems in module core Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 09/13] mm/kstackwatch: Add architecture support validation Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 10/13] mm/kstackwatch: Handle nested function calls Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 11/13] mm/kstackwatch: Ignore corruption in kretprobe trampolines Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 12/13] mm/kstackwatch: Add debug and test functions Jinchao Wang
2025-08-18 12:26 ` [RFC PATCH 13/13] mm/kstackwatch: Add a test module and script Jinchao Wang
2025-08-25 10:31 ` [RFC PATCH 07/13] mm/kstackwatch: Add kprobe and stack watch control Masami Hiramatsu
2025-08-25 13:11 ` Jinchao Wang
2025-09-01 7:06 ` [RFC PATCH 02/13] x86/HWBP: Add arch_reinstall_hw_breakpoint() for atomic updates Masami Hiramatsu
2025-09-01 10:23 ` Jinchao Wang [this message]
2025-09-02 14:11 ` Masami Hiramatsu
2025-09-03 7:58 ` Jinchao Wang
2025-09-04 0:53 ` Jinchao Wang
2025-09-04 1:02 ` Masami Hiramatsu
2025-09-04 1:15 ` 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=284d5eef-447f-4e12-a121-3742d708c96f@gmail.com \
--to=wangjinchao600@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=naveen@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;
as well as URLs for NNTP newsgroup(s).