Re: [PATCH v1] kernel: add a simple timer based software watchpoint

[Feng Tang]

Hi David,

On Mon, Jun 22, 2026 at 04:13:37PM +0200, David Hildenbrand (Arm) wrote:
> 
> >>> This provides the basic function, and there are more todoes:
> >>>   * add a ftrace mode to do function level monitoring with ftrace hook,
> >>>     which is more accurate timing wise, as suggested by Steven Rostedt
> >>>   * merge the dram/mmio interface to auto detect it's dram or mmio
> >>>   * support runtime changing the address
> >>>   * move the starting point earlier in boot phase
> >>>   * monitor a whole memory region
> >>>   * currently is monitoring 'changing to a value', add support
> >>>     for 'changing from a value'
> >>
> >> That really looks more like the kind of thing you would want to carry as a OOT
> >> hack for your special debugging needs :)
> > 
> > Thanks for the review and bringing up a very good question that whether
> > the patch is worthy!
> > 
> > Personally, I think it is.  
> 
> The problem is that the interface is odd (kernel parameters) and the
> implementation is shaky (what happens if memory does not exist? What happens if
> we unplug memory?).

The concern makes sense to me. 

IIUC, the risk of using this patch is similar to the usage of "/dev/mem".
Currently this kconfig depends on DEBUG_KERNEL, so how about making it 

	"depends on DEBUG_KERNEL && IO_STRICT_DEVMEM" (depends on STRICT_DEVMEM)

and warn clearly it is only for kernel issue debugging and "Use with care!"
in kconfig help text and code comments?

As discussed in RFC patch review, this debug feature is similar to
soft/hard lockup detector and task-hung detector, should I make the control
interface to sysctl interface following them, and reduce the control knobs?
The dram and mmio interfaces can be merged, and 'check_once', 'panic_on_hit'
could be removed if necessary.

How do you think? 

Thanks,
Feng

> I don't think it's a good use of our time to polish all that up and then
> maintain it.
> 
> -- 
> Cheers,
> 
> David