Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751740AbdG1DxJ (ORCPT <rfc822;w@1wt.eu>);
        Thu, 27 Jul 2017 23:53:09 -0400
Received: from szxga01-in.huawei.com ([45.249.212.187]:10289 "EHLO
        szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751628AbdG1DxI (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 27 Jul 2017 23:53:08 -0400
Subject: Fwd: trinity test fanotify cause hungtasks on kernel 4.13
References: <5979B8A5.205@huawei.com>
From: Gu Zheng <guzheng1@huawei.com>
To: <eparis@redhat.com>, <viro@zeniv.linux.org.uk>,
        Jan Kara <jack@suse.cz>
CC: <linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        "miaoxie@huawei.com" <miaoxie@huawei.com>
X-Forwarded-Message-Id: <5979B8A5.205@huawei.com>
Message-ID: <597AB4ED.9090306@huawei.com>
Date: Fri, 28 Jul 2017 11:52:13 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <5979B8A5.205@huawei.com>
Content-Type: text/plain; charset="gbk"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.177.97.87]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
        refid=str=0001.0A020206.597AB4F8.002F,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0,
        ip=0.0.0.0,
        so=2014-11-16 11:51:01,
        dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: cdb80102e9aa65bc03f3c1efc72f6aa1
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3989
Lines: 79


hi,ALL:
when we used the trinity test the fanotify interfaces, it cause many hungtasks.
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y
the shell is  simple:
   1 #!/bin/bash
   2
   3 while true
   4 do
   5 ./trinity -c fanotify_init -l off -C 2 -X > /dev/null 2>&1 &
   6 sleep 1
   7 ./trinity -c fanotify_mark -l off -C 2 -X > /dev/null 2>&1 &
   8 sleep 10
   9 done
we found the trinity enter the D state fastly.
we check the pids'stack
[root@localhost ~]# ps -aux | grep D
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       977  0.0  0.0 207992  7904 ?        Ss   15:23   0:00 /usr/bin/abrt-watch-log -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locking detected ernel BUG at list_del corruption list_add corruption do_IRQ: stack overflow: ear stack overflow (cur: eneral protection fault nable to handle kernel ouble fault: RTNL: assertion failed eek! page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl table check failed : nobody cared IRQ handler type mismatch Machine Check Exception: Machine check events logged divide error: bounds: coprocessor segment overrun: invalid TSS: segment not present: invalid opcode: alignment check: stack segment: fpu exception: simd exception: iret exception: /var/log/messages -- /usr/bin/abrt-dump-oops -xtD
root       997  0.0  0.0 203360  3188 ?        Ssl  15:23   0:00 /usr/sbin/gssproxy -D
root      1549  0.0  0.0  82552  6012 ?        Ss   15:23   0:00 /usr/sbin/sshd -D
root      2807  3.5  0.2  59740 35416 pts/0    DL   15:24   0:00 ./trinity -c fanotify_init -l off -C 2 -X
root      2809  3.1  0.2  53712 35332 pts/0    DL   15:24   0:00 ./trinity -c fanotify_mark -l off -C 2 -X
root      2915  0.0  0.0 136948  1776 pts/0    D    15:24   0:00 ps ax
root      2919  0.0  0.0 112656  2100 pts/1    S+   15:24   0:00 grep --color=auto D
[root@localhost ~]# cat /proc/2807/stack
[<ffffffff95287551>] fanotify_handle_event+0x2a1/0x2f0
[<ffffffff95283c13>] fsnotify+0x2d3/0x4f0
[<ffffffff952f3a89>] security_file_open+0x89/0x90
[<ffffffff95239819>] do_dentry_open+0x139/0x330
[<ffffffff9523ad9f>] vfs_open+0x4f/0x70
[<ffffffff9524c428>] path_openat+0x548/0x1350
[<ffffffff9524ea51>] do_filp_open+0x91/0x100
[<ffffffff9523b174>] do_sys_open+0x124/0x210
[<ffffffff9523b27e>] SyS_open+0x1e/0x20
[<ffffffff95003857>] do_syscall_64+0x67/0x150
[<ffffffff95741de7>] entry_SYSCALL64_slow_path+0x25/0x25
[<ffffffffffffffff>] 0xffffffffffffffff

[root@localhost ~]# cat /proc/2915/stack
[<ffffffff95287551>] fanotify_handle_event+0x2a1/0x2f0
[<ffffffff95283c13>] fsnotify+0x2d3/0x4f0
[<ffffffff952f3a89>] security_file_open+0x89/0x90
[<ffffffff95239819>] do_dentry_open+0x139/0x330
[<ffffffff9523ad9f>] vfs_open+0x4f/0x70
[<ffffffff9524c428>] path_openat+0x548/0x1350
[<ffffffff9524ea51>] do_filp_open+0x91/0x100
[<ffffffff9523b174>] do_sys_open+0x124/0x210
[<ffffffff9523b27e>] SyS_open+0x1e/0x20
[<ffffffff95003857>] do_syscall_64+0x67/0x150
[<ffffffff95741de7>] entry_SYSCALL64_slow_path+0x25/0x25
[<ffffffffffffffff>] 0xffffffffffffffff
[root@localhost ~]# cat /proc/2809/stack
[<ffffffff95287551>] fanotify_handle_event+0x2a1/0x2f0
[<ffffffff95283c13>] fsnotify+0x2d3/0x4f0
[<ffffffff952f3a89>] security_file_open+0x89/0x90
[<ffffffff95239819>] do_dentry_open+0x139/0x330
[<ffffffff9523ad9f>] vfs_open+0x4f/0x70
[<ffffffff9524c428>] path_openat+0x548/0x1350
[<ffffffff9524ea51>] do_filp_open+0x91/0x100
[<ffffffff9523b174>] do_sys_open+0x124/0x210
[<ffffffff9523b27e>] SyS_open+0x1e/0x20
[<ffffffff95003857>] do_syscall_64+0x67/0x150
[<ffffffff95741de7>] entry_SYSCALL64_slow_path+0x25/0x25
[<ffffffffffffffff>] 0xffffffffffffffff

all progresses are waiting for the response in fanotify_handle_event->fanotify_get_response,
becauseof non-response or killed monitor,so the waitqueue is  in blocked state,
then the others will be stucked which use the  fanotify_get_response.



if we use wait_event_timeout , the responed time can not be guaranteed.

do you have any ideas?
thanks.