Re: [linus:master] [maple_tree] 120b116208: INFO:task_blocked_for_more_than#seconds

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

 



Hi Paul, Hi Liam,

On Tue, Jan 31, 2023 at 12:52:21PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 31, 2023 at 03:45:20PM -0500, Liam R. Howlett wrote:
> > * Paul E. McKenney <paulmck@xxxxxxxxxx> [230131 15:26]:
> > > On Tue, Jan 31, 2023 at 03:18:22PM +0800, kernel test robot wrote:
> > > > Hi Liam,
> > > > 
> > > > We caught a "task blocked" dmesg in maple tree test. Not sure if this
> > > > is expected for maple tree test, so we are sending this report for
> > > > your information. Thanks.
> > > > 
> > > > Greeting,
> > > > 
> > > > FYI, we noticed INFO:task_blocked_for_more_than#seconds due to commit (built with clang-14):
> > > > 
> > > > commit: 120b116208a0877227fc82e3f0df81e7a3ed4ab1 ("maple_tree: reorganize testing to restore module testing")
> > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > > > 
> > > > in testcase: boot
> > > > 
> > > > on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
> > > > 
> > > > caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
> > > > 
> > > > 
> > > > [   17.318428][    T1] calling  maple_tree_seed+0x0/0x15d0 @ 1
> > > > [   17.319219][    T1] 
> > > > [   17.319219][    T1] TEST STARTING
> > > > [   17.319219][    T1] 
> > > > [  999.249871][   T23] INFO: task rcu_scale_shutd:59 blocked for more than 491 seconds.
> > > > [  999.253363][   T23]       Not tainted 6.1.0-rc4-00003-g120b116208a0 #1
> > > > [  999.254249][   T23] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > > [  999.255390][   T23] task:rcu_scale_shutd state:D stack:30968 pid:59    ppid:2      flags:0x00004000
> > > > [  999.256934][   T23] Call Trace:
> > > > [  999.257418][   T23]  <TASK>
> > > > [  999.257900][   T23]  __schedule+0x169b/0x1f90
> > > > [  999.261677][   T23]  schedule+0x151/0x300
> > > > [  999.262281][   T23]  ? compute_real+0xe0/0xe0
> > > > [  999.263364][   T23]  rcu_scale_shutdown+0xdd/0x130
> > > > [  999.264093][   T23]  ? wake_bit_function+0x2c0/0x2c0
> > > > [  999.268985][   T23]  kthread+0x309/0x3a0
> > > > [  999.269958][   T23]  ? compute_real+0xe0/0xe0
> > > > [  999.270552][   T23]  ? kthread_unuse_mm+0x200/0x200
> > > > [  999.271281][   T23]  ret_from_fork+0x1f/0x30
> > > > [  999.272385][   T23]  </TASK>
> > > > [  999.272865][   T23] 
> > > > [  999.272865][   T23] Showing all locks held in the system:
> > > > [  999.273988][   T23] 2 locks held by swapper/0/1:
> > > > [  999.274684][   T23] 1 lock held by khungtaskd/23:
> > > > [  999.275400][   T23]  #0: ffffffff88346e00 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x8/0x30
> > > > [  999.277171][   T23] 
> > > > [  999.277525][   T23] =============================================
> > > > [  999.277525][   T23] 
> > > > [ 1049.050884][    T1] maple_tree: 12610686 of 12610686 tests passed
> > > > 
> > > > 
> > > > If you fix the issue, kindly add following tag
> > > > | Reported-by: kernel test robot <yujie.liu@xxxxxxxxx>
> > > > | Link: https://lore.kernel.org/oe-lkp/202301310940.4a37c7af-yujie.liu@xxxxxxxxx
> > > 
> > > Liam brought this to my attention on IRC, and it looks like the root
> > > cause is that the rcuscale code does not deal gracefully with grace
> > > periods that are in much excess of a second in duration.
> > > 
> > > Now, it might well be worth looking into why the grace periods were taking
> > > that long, but if you were running Maple Tree stress tests concurrently
> > > with rcuscale, this might well be expected behavior.
> > > 
> > 
> > This could be simply cpu starvation causing no foward progress in your
> > tests with the number of concurrent running tests and "-smp 2".
> > 
> > It's also worth noting that building in the rcu test module makes the
> > machine turn off once the test is complete.  This can be seen in your
> > console message:
> > [   13.254240][    T1] rcu-scale:--- Start of test: nreaders=2 nwriters=2 verbose=1 shutdown=1
> > 
> > so your machine may not have finished running through the array of tests
> > you have specified to build in - which is a lot.  I'm not sure if this
> > is the best approach considering the load that produces on the system
> > and how difficult it is (was) to figure out which test is causing a
> > stall, or other issue.
> 
> Agreed, both rcuscale and refscale when built in turn the machine off at
> the end of the test.  For providing background stress for some other test
> (in this case Maple Tree tests), rcutorture, locktorture, or scftorture
> might be better choices.

Thanks for looking into this. This is a boot test on a randconfig
kernel, and yes, it happend to select CONFIG_RCU_SCALE_TEST=y together
with CONFIG_TEST_MAPLE_TREE=y, leading to the situation in this case.

I've tested the patch on same config, it does clear up the "task
blocked" log, though it still waits a long time at this step. The test
result is as follows:

[   18.397784][    T1] calling  maple_tree_seed+0x0/0x15d0 @ 1
[   18.398646][    T1]
[   18.398646][    T1] TEST STARTING
[   18.398646][    T1]
[ 1266.450656][    T1] maple_tree: 12610686 of 12610686 tests passed
[ 1266.451749][    T1] initcall maple_tree_seed+0x0/0x15d0 returned 0 after 1248053116 usecs
...

=========================================================================================
compiler/kconfig/rootfs/sleep/tbox_group/testcase:
  clang-14/x86_64-randconfig-a006-20230116/yocto-x86_64-minimal-20190520.cgz/300/vm-snb/boot

commit:
  120b116208a08 ("maple_tree: reorganize testing to restore module testing")
  4b1aafbdb208f ("rcuscale: Move shutdown from wait_event() to wait_event_idle()")

120b116208a08    4b1aafbdb208fb4e10bf7abff1a
---------------- ---------------------------
       fail:runs  %reproduction    fail:runs
           |             |             |
          5:6          -83%            :6     dmesg.INFO:task_blocked_for_more_than#seconds

Tested-by: Yujie Liu <yujie.liu@xxxxxxxxx>

--
Best Regards,
Yujie




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux