Re: [QUESTION] Hung task warning while running syzkaller test

[Zhihao Cheng]

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...
>>
>> .