RE: [PATCH v2] rcutorture: Convert schedule_timeout_uninterruptible() to mdelay() in rcu_torture_stall()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Qiang,

> From: Zqiang <qiang1.zhang@xxxxxxxxx>
> Sent: Monday, March 20, 2023 11:24 AM
> To: paulmck@xxxxxxxxxx; frederic@xxxxxxxxxx; joel@xxxxxxxxxxxxxxxxx
> Cc: rcu@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: [PATCH v2] rcutorture: Convert schedule_timeout_uninterruptible()
> to mdelay() in rcu_torture_stall()
> 
> For kernels built with enable PREEMPT_NONE and

s/enable/enabling/

> CONFIG_DEBUG_ATOMIC_SLEEP, running the RCU stall tests.

s/running/run

> 
> runqemu kvm slirp nographic qemuparams="-m 1024 -smp 4"
> bootparams="nokaslr console=ttyS0 rcutorture.stall_cpu=30
> rcutorture.stall_no_softlockup=1 rcutorture.stall_cpu_irqsoff=1
> rcutorture.stall_cpu_block=1" -d
> 
> [   10.841071] rcu-torture: rcu_torture_stall begin CPU stall
> [   10.841073] rcu_torture_stall start on CPU 3.
> [   10.841077] BUG: scheduling while atomic: rcu_torture_sta/66/0x0000000
> ....
> [   10.841108] Call Trace:
> [   10.841110]  <TASK>
> [   10.841112]  dump_stack_lvl+0x64/0xb0
> [   10.841118]  dump_stack+0x10/0x20
> [   10.841121]  __schedule_bug+0x8b/0xb0
> [   10.841126]  __schedule+0x2172/0x2940
> [   10.841157]  schedule+0x9b/0x150
> [   10.841160]  schedule_timeout+0x2e8/0x4f0
> [   10.841192]  schedule_timeout_uninterruptible+0x47/0x50
> [   10.841195]  rcu_torture_stall+0x2e8/0x300
> [   10.841199]  kthread+0x175/0x1a0
> [   10.841206]  ret_from_fork+0x2c/0x50
> 
> The above calltrace occurs in the local_irq_disable/enable() critical section
> call schedule_timeout(), and invoke schedule_timeout() also implies a
> quiescent state, of course it also fails to trigger RCU stall, this commit
> therefore use mdelay() instead of schedule_timeout() to trigger RCU stall.

Tweak the commit description above to fix some grammar errors:

    The above call trace occurred in the local_irq_disable/enable() critical section
    when calling schedule_timeout() from rcu_torture_stall(). Invoking schedule_timeout() 
    also implies a quiescent state, of course, it also fails to trigger RCU stall. This commit, 
    therefore, uses mdelay() instead of schedule_timeout() to trigger the RCU stall.

> Suggested-by: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
> Signed-off-by: Zqiang <qiang1.zhang@xxxxxxxxx>

I didn't reproduce the call trace after applying your patch.
So, with the above minor fixes, then

    Tested-by: Qiuxu Zhuo <qiuxu.zhuo@xxxxxxxxx>

Thanks
-Qiuxu

> ---
>  kernel/rcu/rcutorture.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c index
> d06c2da04c34..a08a72bef5f1 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -2472,7 +2472,7 @@ static int rcu_torture_stall(void *args)  #ifdef
> CONFIG_PREEMPTION
>  				preempt_schedule();
>  #else
> -				schedule_timeout_uninterruptible(HZ);
> +				mdelay(jiffies_to_msecs(HZ));
>  #endif
>  			} else if (stall_no_softlockup) {
>  				touch_softlockup_watchdog();
> --
> 2.25.1





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux