lkml.org 
[lkml]   [2010]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [GIT PULL] notification tree - try 37!
Date
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


\
 
 \ /
  Last update: 2010-08-16 22:35    [W:0.665 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site