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 35BDD3C277C for ; Fri, 26 Jun 2026 06:50:22 +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=1782456625; cv=none; b=R1xPp7Kypc3ISofAqon2FxUcmpa/7TaQaRTYdPT9bwAXCuUCOznbfQrYQXndoTjg4wx9bNlZKu6oeCojQfFHNE8H3kHxo8MykWv80PPx5XAFe/sxWfGxqR/aWpEIA8uQYzG+qk0vcQtThiZJ/kFbfjDo6CPkR5ARh4/nt00L2YI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782456625; c=relaxed/simple; bh=lJd7LrK09H4DBTERXqf9p1rvRgHnQc8ja7kGTow8RL8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=R+rEjZpOJDFHUCY0ORQdy60nKCk09x3f7MQ//oVhUTAYcRiWsbwREoCu9MbdXKoS+khTSOC7KQapvpPxn3QnDHJcltdsDScVGSxivoGW523Bc4xogM+3/Eb9DHXwmAAz1qiacjcvSralqA3jzN7aMlPtnuUN4goJDQt6Cm8Y/u4= 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=XA7ZFq1d; 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="XA7ZFq1d" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1782456613; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=iIxzX/TX+o0DSbB4HfMHeZ+w6eOLqktWaT+9KmHF0LM=; b=XA7ZFq1dnsNh3UiZ+CWVuSe31Nys+2mQroNgFJ8qKYS0jUfUN72EYAaHIVMVoSeDVOd/6pmNc+JBY677n+lHTOaIlA/qImXDfBRRUEwJUdkECuzDXRQCXSFSk78MSLSmOhsRHYELQiBeWAwNM7S8msOWOdRqFM8fMrWRUXocwFE= 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-contentspam011083073210;MF=feng.tang@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0X5dpmUf_1782456612; Received: from localhost(mailfrom:feng.tang@linux.alibaba.com fp:SMTPD_---0X5dpmUf_1782456612 cluster:ay36) by smtp.aliyun-inc.com; Fri, 26 Jun 2026 14:50:12 +0800 Date: Fri, 26 Jun 2026 14:50:11 +0800 From: Feng Tang To: Thomas Gleixner , Steven Rostedt Cc: "David Hildenbrand (Arm)" , Andrew Morton , Petr Mladek , 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> 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: On Fri, Jun 26, 2026 at 09:56:22AM +0800, Feng Tang wrote: > > 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. > > My thought was if I used this method, I could have found the corruption > happen right after the initialization of the module which has that array. In RFC review, Steven suggested using ftrace hook way instead of timer. If we inject the monitoring into the ftrace hook on function exit path, it should be able to catch exactly which function corrupt this variable. Thanks, Feng