linux-kernel - RE: [PATCH v2] rcutorture: Convert schedule_timeout_uninterruptible() to mdelay() in rcu_torture

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

Message-ID: <IA1PR11MB617139069496A8E9FD84BF1689819@IA1PR11MB6171.namprd11.prod.outlook.com>
Date:   Tue, 21 Mar 2023 12:27:14 +0000
From:   "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>
To:     "paulmck@...nel.org" <paulmck@...nel.org>,
        "Zhang, Qiang1" <qiang1.zhang@...el.com>
CC:     "frederic@...nel.org" <frederic@...nel.org>,
        "joel@...lfernandes.org" <joel@...lfernandes.org>,
        "rcu@...r.kernel.org" <rcu@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2] rcutorture: Convert schedule_timeout_uninterruptible()
 to mdelay() in rcu_torture_stall()

> From: Paul E. McKenney <paulmck@...nel.org>
> [...]
> > But invoke schedule_timeout_uninterruptible(HZ) implies a quiescent
> > state, this will not cause an RCU stall to occur, and still in the RCU read
> critical section(PREEMPT_COUNT=y).
> >
> > It didn't happen RCU stall when I tested with the following parameters
> > for
> > rcutorture.stall_cpu=30
> > rcutorture.stall_no_softlockup=1
> > rcutorture.stall_cpu_irqsoff=1
> > rcutorture.stall_cpu_block=1
> 
> Understood.  If you want that RCU CPU stall in a CONFIG_PREEMPTION=n
> kernel, you should not use rcutorture.stall_cpu_block=1.
>

Verified.

if rcutorture.stall_cpu_block=0, it can trigger the expected RCU CPU stall for either 
torture_type=srcu or torture_type=rcu. 
 
> In a CONFIG_PREEMPTION=y kernel, rcutorture.stall_cpu_block=1 forces the
> grace period to be stalled on a task rather than a CPU, exercising a different
> part of the RCU CPU stall warning code.
> 
> In a CONFIG_PREEMPTION=n kernel, using rcutorture.stall_cpu_block=1
> forces the CPU to go through a quiescent state, as you say.  It can also cause
> lockdep and scheduling-while-atomic complaints, depending on exactly what
> type of RCU reader is in effect.
> 

Verified.

If rcutorture.stall_cpu_block=1:
    There were lockdep and scheduling-while-atomic complaints for torture_type=rcu.
    No lockdep and scheduling-while-atomic complaints for torture_type=srcu.

> So these are test-the-diagnostics parameters.  The mdelay() instead makes
> rcutorture.stall_cpu_block=1 do the same thing as does
> rcutorture.stall_cpu_block=0 for CONFIG_PREEMPTION=n kernels, right?

Good to know that these are test-the-diagnostics parameters and their expected behaviors.  ;-)
Thanks!

-Qiuxu

> 							Thanx, Paul