linux-kernel - Re: There is a Tasks RCU stall warning

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 Apr 2017 17:31:33 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: There is a Tasks RCU stall warning

On Tue, 11 Apr 2017 14:18:02 -0700
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:

> Hello, Steve,
> 
> Network connectivity issues...  :-/
> 
> There is already a Tasks RCU stall warning, but it waits for
> ten -minutes- before complaining.  You can change this with the
> rcupdate.rcu_task_stall_timeout kernel boot parameter, if you wish.
> 
> Or did you wait longer than ten minutes?
> 

Remember when I said I had a bunch of debugging turned on in this
kernel. Well, I also included my ftrace trace_event benchmark code.
Which appears to be what is triggering this.

[  205.159860] INFO: rcu_tasks detected stalls on tasks:
[  205.165042] ffff8800c40450c0: .. nvcsw: 2/2 holdout: 1 idle_cpu: -1/1
[  205.171627] event_benchmark R  running task    30224  1113      2 0x10000000
[  205.178829] Call Trace:
[  205.181379]  __schedule+0x574/0x1210
[  205.185061]  ? __schedule+0x574/0x1210
[  205.188917]  ? mark_held_locks+0x23/0xc0
[  205.192944]  ? mark_held_locks+0x23/0xc0
[  205.196964]  ? retint_kernel+0x2d/0x2d
[  205.200831]  ? retint_kernel+0x2d/0x2d
[  205.204679]  ? trace_hardirqs_on_caller+0x182/0x280
[  205.209660]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[  205.214380]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[  205.219097]  irq_exit+0x91/0x100
[  205.222418]  ? retint_kernel+0x2d/0x2d
[  205.226263]  ? retint_kernel+0x2d/0x2d
[  205.230113]  ? kthread_should_stop+0x3d/0x60
[  205.234486]  ? __asan_load8+0x11/0x70
[  205.238245]  ? ring_buffer_record_is_on+0x11/0x20
[  205.243052]  ? tracing_is_on+0x15/0x30
[  205.246895]  ? benchmark_event_kthread+0x4f/0x3c0
[  205.251708]  ? kthread+0x178/0x1d0
[  205.255200]  ? trace_benchmark_reg+0x80/0x80
[  205.259563]  ? kthread_create_on_node+0xa0/0xa0
[  205.264205]  ? ret_from_fork+0x2e/0x40

The thread gets created when I enable the benchmark tracepoint. It just
so happens that my test enables *all* tracepoints, which would of
course include this one as well.

I'll have to look at this code to see why it is getting missed.

-- Steve