Messages in this thread | | | Subject | Re: [QUESTION] Hung task warning while running syzkaller test | From | Zhihao Cheng <> | Date | Tue, 29 Oct 2019 17:09:04 +0800 |
| |
PS: Both preemption enabled or disabled, and the hung task will appear.
在 2019/10/29 10:25, Zhihao Cheng 写道: > I don't know much about the freezer mechanism of CGroup, but I tried it. I turned off all the CGroup related config options and reproduced the hung task on a fresh busybox-made root file system. I added rootfs in attachment. So, I guess hung task has nothing to do with CGroup(freezer). > > > ~ # mount > rootfs on / type rootfs (rw,size=2005040k,nr_inodes=501260) > nodev on /proc type proc (rw,relatime) > nodev on /sys type sysfs (rw,relatime) > nodev on /dev type devtmpfs (rw,relatime,size=2005056k,nr_inodes=501264,mode=755) > devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000) > > --- > > 2019/10/29 02:22:04 executed programs: 190 > 2019/10/29 02:22:10 executed programs: 191 > [ 280.639337] INFO: task syz-executor.14:3190 blocked for more than 140 seconds. > [ 280.641762] Not tainted 4.4.197-514.55.6.9.x86_64+ #276 > [ 280.642746] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 280.644003] syz-executor.14 D ffff8800b3247c60 13864 3190 3189 0x00000000 > [ 280.645190] ffff8800b3247c60 0000000000000006 000000007dc6b6e8 ffffffff00000000 > [ 280.646469] ffff880137071d80 ffff880138771d80 ffff8800b3248000 0000000000000246 > [ 280.647750] ffff8800b79117b0 ffff880138771d80 00000000ffffffff ffff8800b3247c78 > [ 280.649015] Call Trace: > [ 280.649439] [<ffffffff81b0b4f2>] schedule+0x32/0x90 > [ 280.650250] [<ffffffff81b0ba15>] schedule_preempt_disabled+0x15/0x20 > [ 280.651302] [<ffffffff81b0e94b>] mutex_lock_nested+0x17b/0x4f0 > [ 280.652264] [<ffffffff812f5d1e>] ? walk_component+0x23e/0x5f0 > [ 280.653223] [<ffffffff812f5d1e>] walk_component+0x23e/0x5f0 > [ 280.654137] [<ffffffff812f2db4>] ? inode_permission+0x14/0x50 > [ 280.655083] [<ffffffff812f6153>] ? link_path_walk+0x83/0x5d0 > [ 280.656009] [<ffffffff812f6feb>] ? path_lookupat+0x1b/0x120 > [ 280.656923] [<ffffffff812f7023>] path_lookupat+0x53/0x120 > [ 280.657811] [<ffffffff812f952f>] filename_lookup+0xaf/0x170 > [ 280.658732] [<ffffffff812e2052>] ? __check_object_size+0x102/0x1d7 > [ 280.659744] [<ffffffff8161c496>] ? strncpy_from_user+0x46/0x160 > [ 280.660712] [<ffffffff812f96c6>] user_path_at_empty+0x36/0x40 > [ 280.661657] [<ffffffff81316b73>] path_removexattr+0x43/0xb0 > [ 280.662580] [<ffffffff81005017>] ? trace_hardirqs_on_thunk+0x17/0x19 > [ 280.663622] [<ffffffff81317c90>] SyS_lremovexattr+0x10/0x20 > [ 280.664537] [<ffffffff81b129a1>] entry_SYSCALL_64_fastpath+0x1e/0x9a > [ 280.665573] 1 lock held by syz-executor.14/3190: > [ 280.666322] #0: (&type->i_mutex_dir_key){+.+.+.}, at: [<ffffffff812f5d1e>] walk_component+0x23e/0x5f0 > > > 在 2019/10/29 1:54, Valentin Schneider 写道: >> On 26/10/2019 03:48, Zhihao Cheng wrote:> 3. You can convert the repro file into a C program by 'syzprog' tool(see syzprog.c). Using compiled syzprog.c directly for testing did not show hung task, which confused me. >> Good to know that you can get a readable program out of this, but that diff >> in behaviour isn't reassuring. >> >> Also, I don't see anything in there that would try to play with cgroups - I >> was mostly curious about the use of the freezer, but don't see any in the >> C code. Out of curiosity I ran a similar kernel that I tried before (without >> the right configs), and it doesn't complain about missing cgroup options... >> >> .
| |