linux-kernel - Re: RCU CPU stall Warnings with JTAG debugging

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 16 May 2018 08:24:53 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Ehson Hussain <ehson_husain@...mail.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: RCU CPU stall Warnings with JTAG debugging

On Wed, May 16, 2018 at 01:45:45PM +0000, Ehson Hussain wrote:
> Hello Paul,
> 
> Hope you're doing great. I'm trying JTAG debugging on an aarch64 SoC (Xilinx Zynqmp zcu102 to be precise); when I halt the cores manually, or hit a breakpoint, I get a CPU stall warning on resuming after the RCU grace period expires.
> 
> If I resume quickly enough, I do not get the warning.
> 
> My question is, if all cores are stopped during debugging, how does RCU code detect/self-detect stalls on CPU? I have never observed this behavior in older kernels (3.14 and above), with arm cores e.g. armv7 based Freescale iMx6 boards.

My guess is that the jiffies clock is updated after resume to allow for
the time elapsed during the halt.  So the system resumes, the jiffies
counter gets a huge increment, and RCU complains about the massive
passage of time.

If you are doing JTAG debugging, I recommend shutting off RCU CPU stall
warnings, for example, using the rcupdate.rcu_cpu_stall_suppress kernel
boot parameter.

I suppose you could also tweak the clock code to pretend that no time
passes while halted, but that could be a very tricky task.

							Thanx, Paul