From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-99.freemail.mail.aliyun.com (out30-99.freemail.mail.aliyun.com [115.124.30.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 11CC43DD500 for ; Mon, 29 Jun 2026 08:35:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.99 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782722142; cv=none; b=iyiqFZ5p9ETtxDEV80doKkbTZppL8E55fuqZtLoyuDkf1UBg4RuPtYIhWyzuyOWmbj/M1gXLVOrc5+1uTA3ahwm5ywk5wQ6Rj8HMBSq8ftb2d+K0dhFsKx23C+MNdv+TG6FTAnM4lMLQAykR+J4hxN3+0hwsikq7QCcXXRIwS9M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782722142; c=relaxed/simple; bh=ceL5ZRdadXm2UUZ3gxSKYTN4w+YmgXq+oFbzUmcMrM4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=e9DaCf6z/zJpaLGnl1LQwrAJ7phxkVsVCwPTVaJmQ4kmpdGsddO5TlP5XhUddDPon2t+kqXj6NIHMaZrl4j3WcJ7pdr68ExJvDKLmLw/Chja4fCT3EWIVg+/j+RS/10kzCrynkQIsxfiL/YxPE1kYgrT1Pw8UonFetibJklHtm4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=t+SJ1JNh; arc=none smtp.client-ip=115.124.30.99 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="t+SJ1JNh" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1782722136; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=yWCSyVa6K+8arlGI/yDHyQGvcmed7cEPG9zdZVa5c8s=; b=t+SJ1JNh+MdgEwCYIRtTTNHOJk3U4EQjYwQ0l6TPGcnBlNygwgx5dtaNXe8KLP9/CX5T5YwG9CTWeBJejQg1K0oA59PXp+4+jA5KQMRY2YzQbomOOpd0G7DX2HxPVSYGatGleFJSJ4MZpCDF5MoIODqTDKlBVRrXxKmCzq1t1E8= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037033178;MF=feng.tang@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0X5q0biF_1782722134; Received: from localhost(mailfrom:feng.tang@linux.alibaba.com fp:SMTPD_---0X5q0biF_1782722134 cluster:ay36) by smtp.aliyun-inc.com; Mon, 29 Jun 2026 16:35:35 +0800 Date: Mon, 29 Jun 2026 16:35:33 +0800 From: Feng Tang To: Thomas Gleixner Cc: "David Hildenbrand (Arm)" , Andrew Morton , Petr Mladek , Steven Rostedt , paulmck@kernel.org, Douglas Anderson , Peter Zijlstra , Vlastimil Babka , linux-kernel@vger.kernel.org, Ard Biesheuvel Subject: Re: [PATCH v1] kernel: add a simple timer based software watchpoint Message-ID: References: <0c39c459-306f-49f5-b08e-e7b9b27b6352@kernel.org> <87a4skl36t.ffs@fw13> <87pl1ejoj4.ffs@fw13> <87jyrlk6g7.ffs@fw13> <87cxxdiaiq.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87cxxdiaiq.ffs@fw13> On Fri, Jun 26, 2026 at 05:31:09PM +0200, Thomas Gleixner wrote: > On Fri, Jun 26 2026 at 22:33, Feng Tang wrote: > > As HW jtag debugger is expensive and not generally available for > > software developer, also many production hardware don't have their > > jtag interface open for security reason, I think monitoring the > > abnormal changes to dram/mmio is convenient for debugging memory > > corruption issues. Could you help to give some suggestion on > > how to redesign this? Many thanks! > > If you can reproduce in a VM, you have qemu + gdb, which allows you > even to debug the BIOS. Yes. I use this in normal work, for issues which can be reproduced in QEMU. > If it's bare metal you can use kgdb or perf events. All of those allow > you to set watchpoints, data breakpoints etc. Thanks for the suggestion! I have never used kgdb before, but rely more on printk/trace_printk :). I went checked it and tried kdb in QEMU, and think it's great and will surely use it. I read some code about kgdb and HW spec for arm-debug. IIUC, some architectures support watching 'write' to memory, but few supports watchpoint by 'physical address'. V1 patch's title about 'watchpoint' is misleading, while the RFC's is more explicit about detecting memory corruption (to dram/mmio by physical address, from devices, broken silicon, BIOS and kernel), which has no dependency over other kernel modules or hardware. It works very basically as long as 'timer' works. Also I failed to explain the issues clearly, let me try again. There are 3 issues discussed: 1. 'zero page' corrupted inside OS due to BIOS enables wrong HW feature, triggering 'segmentation fault' randomly. 2. BIOS runtime service corrupts ACPI_ENABLE register 3. kernel static array overflow issue. For 2 and 3, they can be solved without this patch, which may accelerate the debug though. Only for 3, the patch is necessary as physical address watchpoint is not supported by hardware. Anyway I'll explore more in this area. Thanks for your time reviewing! - Feng > If you end up with no hit on a watch/breakpoint then you're lost in that > case as you can't debug the BIOS w/o a hardware debugger, but that's not > any different than with your magic hack. > > The tools are all there you just have to use them correctly, no? > > Thanks, > > tglx > > > >