[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1248898455.2597.59.camel@localhost>
Date: Wed, 29 Jul 2009 16:14:15 -0400
From: Eric Paris <eparis@...hat.com>
To: Jamie Lokier <jamie@...reable.org>
Cc: Andreas Dilger <adilger@....com>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, malware-list@...sg.printk.net,
Valdis.Kletnieks@...edu, greg@...ah.com, jcm@...hat.com,
douglas.leeder@...hos.com, tytso@....edu, arjan@...radead.org,
david@...g.hm, jengelh@...ozas.de, aviro@...hat.com,
mrkafk@...il.com, alexl@...hat.com, jack@...e.cz,
tvrtko.ursulin@...hos.com, a.p.zijlstra@...llo.nl,
hch@...radead.org, alan@...rguk.ukuu.org.uk, mmorley@....in,
pavel@...e.cz
Subject: Re: fanotify - overall design before I start sending patches
On Mon, 2009-07-27 at 20:23 +0100, Jamie Lokier wrote:
> Andreas Dilger wrote:
> > On Jul 25, 2009 01:29 +0100, Jamie Lokier wrote:
> > > Eric Paris wrote:
> What's wrong with fanotify-using applications generating events when
> they modify files themselves?
>
> An example was given where app A gets an event and modifies the file,
> then app B gets an event and modifies the file, and app A... cycling.
No the example was the 'open' which the kernel does on behalf of the
listener. I'm thinking now I should only exclude
OPEN
OPEN_PERM
ACCESS_PERM
as those are the only 3 event types I can see deadlock/recursion
problems with.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists