Messages in this thread | | | From | Andreas Gruenbacher <> | Subject | Re: [GIT PULL] notification tree - try 37! | Date | Mon, 16 Aug 2010 22:32:36 +0200 |
| |
On Saturday 07 August 2010 21:15:14 Eric Paris wrote: > On Fri, 2010-08-06 at 20:06 -0400, Christoph Hellwig wrote: > > I'm also totally missing on any re-post of these patches or discussion > > of the changes during the last development window. > > I just searched lkml an fsdevel where I usually send everything don't > see then. I totally failed.
Oh yes.
This introduces two new syscalls which will be impossible to fix up after the fact, and those system calls are poorly documented: commits 2a3edf86 and 52c923dd document the initial versions (in the commit message!), but subsequent commits then extend that interface. The interface for replying to events is not documented at all beyond the example code [1]. There is no documentation in Documentation/filesystems/, either.
[1] http://people.redhat.com/~eparis/fanotify/
Q: What happens when a process watching for FAN_OPEN_PERM or FAN_ACCESS_PERM events exits or dies while events are in flight? I can't see anything in the code that would wake sleeping processes up when the fsnotify_group of the listener is torn down.
Q: What prevents the system from going out of memory when a listener decides to stop reading events or simply can't keep up? There doesn't seem to be a limit on the queue depth. Listeners currently need CAP_SYS_ADMIN, but somehow limiting the queue depth and throttling when things start to go bad still sounds like a reasonable thing to do, right?)
Don't get me wrong, I really appreciate your work on this (this shows through the patches I've committed), and what we have now is a lot better than what we had before.
Thanks, Andreas
| |