From: Eric Paris <eparis@redhat.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-kernel@vger.kernel.org, linus-fsdevel@vger.kernel.org,
viro@zeniv.linux.org.uk, hch@infradead.org, agruen@suse.de,
vegard.nossum@gmail.com
Subject: Re: [PATCH 10/10] send events using read
Date: Tue, 03 Nov 2009 19:55:48 -0500 [thread overview]
Message-ID: <1257296148.2891.223.camel@dhcp231-106.rdu.redhat.com> (raw)
In-Reply-To: <20091103165947.35bd78d7@bike.lwn.net>
On Tue, 2009-11-03 at 16:59 -0700, Jonathan Corbet wrote:
> Hi, Eric,
>
> This is not a full review, but I did notice a problem as I was trying to
> figure out the new API...
This is a rip off of inotify which was introduced in commit 3632dee2f8b
from Vegard Nossum back in January. I can't seem to find any discussion
of this before it went into Linus' tree, so if someone knows how this
patch got to Linus and what was said about it, I'd like to know. Thanks
for unwittingly finding and inotify bug!
I looked back over it and it looks to me like it will work although
there may be a race like situation if there are multiple things trying
to read events. I can see how with perfect timing and precision Task A
might try to get the mutex and it is being held by task B. Task B drops
the mutex and Task A gets it, this causes Task A to be TASK_RUNNABLE.
Lets assume Task B runs back around the loop and tries to get it while
Task A still holds it. Task A will drop the mutex and Task B gets it,
now B is runnable. Repeat until infinity with perfect timing! It's not
really a live-lock, if either of them ever gets the mutex uncontested or
if an event ever arrives they are going to sleep and/or break the cycle.
Certainly I'll take a look at it.
> > +static ssize_t fanotify_read(struct file *file, char __user *buf,
> > + size_t count, loff_t *pos)
> > +{
> > + struct fsnotify_group *group;
> > + struct fsnotify_event *kevent;
> > + char __user *start;
> > + int ret;
> > + DEFINE_WAIT(wait);
> > +
> > + start = buf;
> > + group = file->private_data;
> > +
> > + pr_debug("%s: group=%p\n", __func__, group);
> > +
> > + while (1) {
> > + prepare_to_wait(&group->notification_waitq, &wait, TASK_INTERRUPTIBLE);
> > +
> > + mutex_lock(&group->notification_mutex);
> > + kevent = get_one_event(group, count);
> > + mutex_unlock(&group->notification_mutex);
>
> prepare_to_wait(), among other things, sets the task state. But then you
> go into various sleeping calls (mutex_lock(), for starters); that will undo
> what prepare_to_wait has done. You'll be back in TASK_RUNNING at this
> point, so you'll never sleep.
next prev parent reply other threads:[~2009-11-04 0:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-31 18:47 [PATCH 01/10] vfs: introduce FMODE_NONOTIFY Eric Paris
2009-10-31 18:47 ` [PATCH 02/10] fanotify: fscking all notification system Eric Paris
2009-11-06 15:31 ` Eric Paris
2009-11-06 15:54 ` Andreas Gruenbacher
2009-10-31 18:47 ` [PATCH 03/10] fanotify:drop notification if they exist in the outgoing queue Eric Paris
2009-10-31 18:47 ` [PATCH 04/10] fanotify: merge notification events with different masks Eric Paris
2009-10-31 18:47 ` [PATCH 05/10] fanotify: do not clone on merge unless needed Eric Paris
2009-10-31 18:47 ` [PATCH 06/10] fanotify: fanotify_init syscall declaration Eric Paris
2009-10-31 18:48 ` [PATCH 07/10] fanotify: fanotify_init syscall implementation Eric Paris
2009-10-31 18:48 ` [PATCH 08/10] fanotify: sys_fanotify_mark declartion Eric Paris
2009-10-31 18:48 ` [PATCH 09/10] fanotify: fanotify_mark syscall implementation Eric Paris
2009-10-31 18:48 ` [PATCH 10/10] send events using read Eric Paris
2009-11-03 23:59 ` Jonathan Corbet
2009-11-04 0:55 ` Eric Paris [this message]
2009-11-04 8:07 ` Vegard Nossum
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=1257296148.2891.223.camel@dhcp231-106.rdu.redhat.com \
--to=eparis@redhat.com \
--cc=agruen@suse.de \
--cc=corbet@lwn.net \
--cc=hch@infradead.org \
--cc=linus-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vegard.nossum@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®