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]

Message-Id: <20170411215656.GI1600@linux.vnet.ibm.com>
Date:   Tue, 11 Apr 2017 14:56:56 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: There is a Tasks RCU stall warning

On Tue, Apr 11, 2017 at 05:49:53PM -0400, Steven Rostedt wrote:
> On Tue, 11 Apr 2017 14:44:43 -0700
> "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
> 
> 
> > Works for me!
> > 
> > Hopefully it will also work for your computer.  :-)
> > 
> > And whew!  Glad to see that the stall warnings worked!
> 
> Ah! but I think I found a bug in synchronize_rcu_tasks()!
> 
> Calling schedule isn't good enough. For rcu_tasks to continue, the task
> needs to schedule out. With my updated code, I just triggered:
> 
> [  196.276868] INFO: rcu_tasks detected stalls on tasks:
> [  196.284294] ffff8800c26f8040: .. nvcsw: 2/2 holdout: 1 idle_cpu: -1/1
> [  196.293175] event_benchmark R  running task    30536  1127      2 0x10000000
> [  196.302746] Call Trace:
> [  196.307640]  ? _raw_spin_unlock_irq+0x1f/0x50
> [  196.314453]  __schedule+0x222/0x1210
> [  196.320476]  ? pci_mmcfg_check_reserved+0xc0/0xc0
> [  196.327616]  ? preempt_count_add+0xb7/0xf0
> [  196.334174]  ? __asan_store8+0x15/0x70
> [  196.340384]  schedule+0x57/0xe0
> [  196.345888]  benchmark_event_kthread+0x2e/0x3c0
> [  196.352823]  kthread+0x178/0x1d0
> [  196.358411]  ? trace_benchmark_reg+0x80/0x80
> [  196.365073]  ? kthread_create_on_node+0xa0/0xa0
> [  196.371999]  ret_from_fork+0x2e/0x40
> 
> 
> And here my benchmark called schedule(), but nothing scheduled it out,
> and it still fails on rcu_tasks.

Good point!

Hmmmm...  I cannot hook into rcu_note_context_switch() because that gets
called for preemption as well as for voluntary context switches.

How about cond_resched_rcu_qs()?  Does that cover it?

							Thanx, Paul