All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
To: boyd yang <boyd.yang@gmail.com>
Cc: eparis@redhat.com, xiyou.wangcong@gmail.com,
	Josef Bacik <josef@redhat.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fanotify: to differ file access event from different threads
Date: Sat, 10 Dec 2011 17:25:38 +0100	[thread overview]
Message-ID: <20111210162538.GB2773@Neptun> (raw)
In-Reply-To: <CAE8kqZJO_YZ855g2P3803-3ptExDeKX108x-Q_2Rz7rgz1iUew@mail.gmail.com>

On Tue, Dec 06, 2011 at 09:23:25AM +0800, boyd yang wrote:
> fanotify: to differ file access event from different threads
> When fanotify is monitoring the whole mount point "/", and multiple
> threads iterate the same direcotry, some thread will hang.
> This patch let fanotify to differ access events from different
> threads, prevent fanotify from merging access events from different
> threads.

I could reproduce the problem you described. Actually it may occur each time
when more than one thread of a process is waiting in fanotify_get_response() 
at the same time. This is since we are not prepared to wake up more than one 
waiter: We do 

wait_event(group->fanotify_data.access_waitq, event->response ||
			atomic_read(&group->fanotify_data.bypass_perm));

and after that 
  event->response = 0;

which is the reason that even if we woke up other waiters on the same waitqueue
they may see event->response being already 0, go back to sleep and then possibly 
hang forever.

> It also hide overflow events to reach user space.

This is not part of this patch and also should not be, since overflow
events are supposted to reach user space.

> -	if (event->mask & FAN_ALL_PERM_EVENTS) {
> -		/* if we merged we need to wait on the new event */
> -		if (notify_event)
> -			event = notify_event;
> -		ret = fanotify_get_response_from_access(group, event);
> +	/*if overflow, do not wait for response*/
> +	if (event->mask&FS_Q_OVERFLOW) {
> +		pr_debug("fanotify overflow!\n");
> +	}	else {
> +		if (event->mask & FAN_ALL_PERM_EVENTS) {
> +			/* if we merged we need to wait on the new event */
> +			if (notify_event)
> +				event = notify_event;
> +			ret = fanotify_get_response_from_access(group, event);
> +		}
>  	}

What is this for? All you do is introduce a debug message for no real reason.
However your fix (avoid merging of events from the same process) seems to work.

Regards,
Lino

  reply	other threads:[~2011-12-10 16:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-06  1:23 [PATCH] fanotify: to differ file access event from different threads boyd yang
2011-12-10 16:25 ` Lino Sanfilippo [this message]
2013-02-11 19:49 ` Mihai Donțu
  -- strict thread matches above, loose matches on Subject: below --
2011-10-13  8:56 boyd yang
2011-10-13 13:27 ` boyd yang
2011-10-13 14:35   ` Américo Wang
2011-10-13 13:38 ` Josef Bacik
2011-10-14  6:56   ` boyd yang
2011-10-14  6:56     ` boyd yang
2011-11-17 10:21     ` boyd yang
2011-11-24 14:58       ` Jan Kara
2011-12-06  1:24         ` boyd yang
2011-10-10  6:45 boyd yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111210162538.GB2773@Neptun \
    --to=linosanfilippo@gmx.de \
    --cc=boyd.yang@gmail.com \
    --cc=eparis@redhat.com \
    --cc=josef@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.