From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) (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 BADD73F54BF for ; Fri, 26 Jun 2026 14:33:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782484431; cv=none; b=sMjmGG0zQUv9ryaOHkx5e1Ws6YllnKVqqmK9TFk6twirI7Vvc5FSSFV8kgYJho9iJthLiYHzaCSpXQT1IZGArfYjJsvfEH/4iea2QCc9I5D3QSprZ8cB8ZlQIW0vW28C83Ez0G9qly1r/Iwompt96JhK/XpFW2kQw2QV7RfmVC0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782484431; c=relaxed/simple; bh=FOVlK2HCfMj9KmQY76+P1FZsYWmbuPVv2aj2reyQHks=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lbiO1zrxCwgt+ZViewZSOedWkCGBJ+oFQccWb1+wv5WnxlHHAdVARH4OPKNhOSCfOJS5/lthFnBSRKIV4vXLJglgQ7INAX8TAmpKb5AGLWGuFddmZvEmoMptxuSIM9+o89nRHLVyQ+Hotoukgw7/0LFB+EIz3PioOJiwtiuOJ3Q= 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=wKH9iIOd; arc=none smtp.client-ip=115.124.30.133 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="wKH9iIOd" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1782484407; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=7Kkh05v20Z9JKv1fkxkXn4DEdSu4NTKVAdryfUqnLKU=; b=wKH9iIOdodQeyvUdpzQ9B9nrt96fezHEoVvdxX6jMcamFUe2LO24rjnnpObGwIbZ/Ep0a7cGpFzk3Qh8bAi6p8/kYsEHqF5jF7R40BDoANRzWmnp4hzVnTdclXrMveVOWGHLuX/aFTRKfbx3zYDgodOzT9XFiygYG2NMXgFeC2I= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045098064;MF=feng.tang@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0X5fBfKc_1782484406; Received: from localhost(mailfrom:feng.tang@linux.alibaba.com fp:SMTPD_---0X5fBfKc_1782484406 cluster:ay36) by smtp.aliyun-inc.com; Fri, 26 Jun 2026 22:33:27 +0800 Date: Fri, 26 Jun 2026 22:33:25 +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: <20260622081430.37557-1-feng.tang@linux.alibaba.com> <0c39c459-306f-49f5-b08e-e7b9b27b6352@kernel.org> <87a4skl36t.ffs@fw13> <87pl1ejoj4.ffs@fw13> <87jyrlk6g7.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: <87jyrlk6g7.ffs@fw13> On Fri, Jun 26, 2026 at 11:16:08AM +0200, Thomas Gleixner wrote: > > Similarly, I didn't make it clear that the issue was not about address > > translation. > > > > The bug report I got from test engineers was, the ACPI_ENABLE register > > has right value from BIOS boot message, and after booting to OS, it was > > changed to a strange value. So initially the suspect was us OS guy :). > > And we used the 'approching" policy of the method, checked the kernel > > logs (we added many debug ones) before the corruption was detected, and > > found right before the corruption, there was a RTC runtime service > > calling record, and asked BIOS engineer to check, which root caused it. > > > > So the idea was to find the activites before the happening of "corrution", > > and check if there was some clues. > > Again. You failed to structure the problem and use the tools correctly. Yes! For this one, we also concluded it's not OS changing it. As you said, using HW jtag debugger to watchpoint that address for BIOS (usually they use identity mapping, and the virtual address is the same as physical address) should be able to capture the culprit BIOS code precisely. > > >> > Then I tried to recall some old memory corruption issues I've met before, > >> > and think about if there is some that could be captured by this method, > >> > one example was a static global array overflow issue, which corrupted > >> > some other global variables which was next to it in kernel bss segment. > >> > >> No. This is just all catching the problem after the fact with no trace > >> and conclusive information about the root cause. The tools are there, > >> you just have to use them correctly. But sure creating magic hacks which > >> by chance give you the same information is way better... > > > > This issue was interesting. It showed up as a NULL pointer panic, and I > > found it's a global variable (in bss segment) being corrupted (which shouldn't > > happen logically). As it didn't happened on normal platforms, but one platform > > with special config, we think it could be silicon related, and sent it to > > silicon team, who did root cause it with gathering/analyzing silicon traces to > > be an array overflow issue, as the special config make that array much longer. > > Your debug war stories are amazing, but in the wrong way and do not > justify to shove a completely ill defined barely usable hack into the > kernel to be maintained forever. Yes, I agree with you and David that this implementation is hacky and difficult to maintain. 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! - Feng > Thanks, > > tglx