[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170728074509.GA29433@quack2.suse.cz>
Date: Fri, 28 Jul 2017 09:45:09 +0200
From: Jan Kara <jack@...e.cz>
To: Gu Zheng <guzheng1@...wei.com>
Cc: eparis@...hat.com, viro@...iv.linux.org.uk,
Jan Kara <jack@...e.cz>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org,
"miaoxie@...wei.com" <miaoxie@...wei.com>
Subject: Re: Fwd: trinity test fanotify cause hungtasks on kernel 4.13
On Fri 28-07-17 11:52:13, Gu Zheng wrote:
>
> 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
<snip>
> 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.
Yes, this all works as expected.
> if we use wait_event_timeout , the responed time can not be guaranteed.
>
> do you have any ideas?
So if your target is sensible trinity testing of fanotify, what you could
do is that you would gather all descriptors where fanotify_init()
succeeded, watch them and reply to all fanotify events. Alternatively you
could just close these descriptors - that would tear down fanotify instance
and all events will be auto-accepted.
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists