linux-kernel - Re: [PATCH v5 7/9] rv: Replace tss and sncid monitors with more complete sts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250730125224.ScWqm03r@linutronix.de>
Date: Wed, 30 Jul 2025 14:52:24 +0200
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
	linux-trace-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Tomas Glozar <tglozar@...hat.com>, Juri Lelli <jlelli@...hat.com>,
	Clark Williams <williams@...hat.com>,
	John Kacur <jkacur@...hat.com>
Subject: Re: [PATCH v5 7/9] rv: Replace tss and sncid monitors with more
 complete sts

On Tue, Jul 29, 2025 at 04:06:17PM +0200, Gabriele Monaco wrote:
> On Tue, 2025-07-29 at 11:37 +0200, Nam Cao wrote:
> > On Tue, Jul 29, 2025 at 11:25:12AM +0200, Nam Cao wrote:
> > > Kernel:
> > >   - base: ftrace/for-next
> 
> I assume you mean rv/for-next ? The one that includes all changes as of
> yesterday.

I meant I apply this series on top of ftrace/for-next. But that one is
close enough.

> Thanks for all the details, but I still can't reproduce nor understand
> what can be triggering the issue.
> 
> I tried enabling sts and setting panic as the reactor (to avoid missing
> it with all the rubbish that gets printed on the dmesg) and run
> testall. Still cannot see the error.

Welcome to the "but it works on my machine" camp. I was there 2 weeks ago,
it was not fun.

> What might help would be to see the trace with irq_enable and
> irq_disable around the error, something like (not tested):
> 
>   trace-cmd stream -e irq_enable -e irq_disable -e error_sts -e
> irq_handler_entry -- sh testall | grep -B 10 error

I do not have trace-cmd in the riscv image, but I do have perf. I will give
it a try.

> The problem here is not when the error occurs, but a couple of events
> earlier (where I possibly miss something that looks like an interrupt).

I just accidentally hit this error again, not on riscv but on x86, while
doing something unrelated. Let me figure out a minimal way to reproduce it.

Nam