1. 12 Aug, 2010 1 commit
  2. 28 Jul, 2010 14 commits
    • Eric Paris's avatar
      vfs/fsnotify: fsnotify_close can delay the final work in fput · c1e5c954
      Eric Paris authored
      fanotify almost works like so:
      
      user context calls fsnotify_* function with a struct file.
         fsnotify takes a reference on the struct path
      user context goes about it's buissiness
      
      at some later point in time the fsnotify listener gets the struct path
         fanotify listener calls dentry_open() to create a file which userspace can deal with
            listener drops the reference on the struct path
      at some later point the listener calls close() on it's new file
      
      With the switch from struct path to struct file this presents a problem for
      fput() and fsnotify_close().  fsnotify_close() is called when the filp has
      already reached 0 and __fput() wants to do it's cleanup.
      
      The solution presented here is a bit odd.  If an event is created from a
      struct file we take a reference on the file.  We check however if the f_count
      was already 0 and if so we take an EXTRA reference EVEN THOUGH IT WAS ZERO.
      In __fput() (where we know the f_count hit 0 once) we check if the f_count is
      non-zero and if so we drop that 'extra' ref and return without destroying the
      file.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      c1e5c954
    • Eric Paris's avatar
      fsnotify: store struct file not struct path · 3bcf3860
      Eric Paris authored
      Al explains that calling dentry_open() with a mnt/dentry pair is only
      garunteed to be safe if they are already used in an open struct file.  To
      make sure this is the case don't store and use a struct path in fsnotify,
      always use a struct file.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      3bcf3860
    • Eric Paris's avatar
      fsnotify: fsnotify_add_notify_event should return an event · f70ab54c
      Eric Paris authored
      Rather than the horrific void ** argument and such just to pass the
      fanotify_merge event back to the caller of fsnotify_add_notify_event() have
      those things return an event if it was different than the event suggusted to
      be added.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      f70ab54c
    • Eric Paris's avatar
      fsnotify: add pr_debug throughout · 5ba08e2e
      Eric Paris authored
      It can be hard to debug fsnotify since there are so few printks.  Use
      pr_debug to allow for dynamic debugging.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      5ba08e2e
    • Eric Paris's avatar
      fsnotify: use unsigned char * for dentry->d_name.name · 59b0df21
      Eric Paris authored
      fsnotify was using char * when it passed around the d_name.name string
      internally but it is actually an unsigned char *.  This patch switches
      fsnotify to use unsigned and should silence some pointer signess warnings
      which have popped out of xfs.  I do not add -Wpointer-sign to the fsnotify
      code as there are still issues with kstrdup and strlen which would pop
      out needless warnings.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      59b0df21
    • Eric Paris's avatar
      fsnotify: intoduce a notification merge argument · 6e5f77b3
      Eric Paris authored
      Each group can define their own notification (and secondary_q) merge
      function.  Inotify does tail drop, fanotify does matching and drop which
      can actually allocate a completely new event.  But for fanotify to properly
      deal with permissions events it needs to know the new event which was
      ultimately added to the notification queue.  This patch just implements a
      void ** argument which is passed to the merge function.  fanotify can use
      this field to pass the new event back to higher layers.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      for fanotify to properly deal with permissions events
      6e5f77b3
    • Andreas Gruenbacher's avatar
      fanotify: Add pids to events · 32c32632
      Andreas Gruenbacher authored
      Pass the process identifiers of the triggering processes to fanotify
      listeners: this information is useful for event filtering and logging.
      Signed-off-by: default avatarAndreas Gruenbacher <agruen@suse.de>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      32c32632
    • Andreas Gruenbacher's avatar
      fsnotify: kill FSNOTIFY_EVENT_FILE · 72acc854
      Andreas Gruenbacher authored
      Some fsnotify operations send a struct file.  This is more information than
      we technically need.  We instead send a struct path in all cases instead of
      sometimes a path and sometimes a file.
      Signed-off-by: default avatarAndreas Gruenbacher <agruen@suse.de>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      72acc854
    • Eric Paris's avatar
      fsnotify: lock annotation for event replacement · cac69dad
      Eric Paris authored
      fsnotify_replace_event need to lock both the old and the new event.  This
      causes lockdep to get all pissed off since it dosn't know this is safe.
      It's safe in this case since the new event is impossible to be reached from
      other places in the kernel.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      cac69dad
    • Eric Paris's avatar
      fsnotify: replace an event on a list · 1201a536
      Eric Paris authored
      fanotify would like to clone events already on its notification list, make
      changes to the new event, and then replace the old event on the list with
      the new event.  This patch implements the replace functionality of that
      process.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      1201a536
    • Eric Paris's avatar
      fsnotify: clone existing events · b4e4e140
      Eric Paris authored
      fsnotify_clone_event will take an event, clone it, and return the cloned
      event to the caller.  Since events may be in use by multiple fsnotify
      groups simultaneously certain event entries (such as the mask) cannot be
      changed after the event was created.  Since fanotify would like to merge
      events happening on the same file it needs a new clean event to work with
      so it can change any fields it wishes.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      b4e4e140
    • Eric Paris's avatar
      fsnotify: per group notification queue merge types · 74766bbf
      Eric Paris authored
      inotify only wishes to merge a new event with the last event on the
      notification fifo.  fanotify is willing to merge any events including by
      means of bitwise OR masks of multiple events together.  This patch moves
      the inotify event merging logic out of the generic fsnotify notification.c
      and into the inotify code.  This allows each use of fsnotify to provide
      their own merge functionality.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      74766bbf
    • Eric Paris's avatar
      fsnotify: use kmem_cache_zalloc to simplify event initialization · 6f3a539e
      Eric Paris authored
      fsnotify event initialization is done entry by entry with almost everything
      set to either 0 or NULL.  Use kmem_cache_zalloc and only initialize things
      that need non-zero initialization.  Also means we don't have to change
      initialization entries based on the config options.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      6f3a539e
    • Eric Paris's avatar
      fsnotify: use fsnotify_create_event to allocate the q_overflow event · b4277d3d
      Eric Paris authored
      Currently fsnotify defines a static fsnotify event which is sent when a
      group overflows its allotted queue length.  This patch just allocates that
      event from the event cache rather than defining it statically.  There is no
      known reason that the current implementation is wrong, but this makes sure the
      event is initialized and created like any other.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      b4277d3d
  3. 18 Oct, 2009 1 commit
  4. 17 Aug, 2009 2 commits
  5. 21 Jul, 2009 3 commits
    • Eric Paris's avatar
      inotify: use GFP_NOFS under potential memory pressure · f44aebcc
      Eric Paris authored
      inotify can have a watchs removed under filesystem reclaim.
      
      =================================
      [ INFO: inconsistent lock state ]
      2.6.31-rc2 #16
      ---------------------------------
      inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
      khubd/217 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (iprune_mutex){+.+.?.}, at: [<c10ba899>] invalidate_inodes+0x20/0xe3
      {IN-RECLAIM_FS-W} state was registered at:
        [<c10536ab>] __lock_acquire+0x2c9/0xac4
        [<c1053f45>] lock_acquire+0x9f/0xc2
        [<c1308872>] __mutex_lock_common+0x2d/0x323
        [<c1308c00>] mutex_lock_nested+0x2e/0x36
        [<c10ba6ff>] shrink_icache_memory+0x38/0x1b2
        [<c108bfb6>] shrink_slab+0xe2/0x13c
        [<c108c3e1>] kswapd+0x3d1/0x55d
        [<c10449b5>] kthread+0x66/0x6b
        [<c1003fdf>] kernel_thread_helper+0x7/0x10
        [<ffffffff>] 0xffffffff
      
      Two things are needed to fix this.  First we need a method to tell
      fsnotify_create_event() to use GFP_NOFS and second we need to stop using
      one global IN_IGNORED event and allocate them one at a time.  This solves
      current issues with multiple IN_IGNORED on a queue having tail drop
      problems and simplifies the allocations since we don't have to worry about
      two tasks opperating on the IGNORED event concurrently.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      f44aebcc
    • Eric Paris's avatar
      fsnotify: fix inotify tail drop check with path entries · c05594b6
      Eric Paris authored
      fsnotify drops new events when they are the same as the tail event on the
      queue to be sent to userspace.  The problem is that if the event comes with
      a path we forget to break out of the switch statement and fall into the
      code path which matches on events that do not have any type of file backed
      information (things like IN_UNMOUNT and IN_Q_OVERFLOW).  The problem is
      that this code thinks all such events should be dropped.  Fix is to add a
      break.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      c05594b6
    • Eric Paris's avatar
      inotify: check filename before dropping repeat events · 4a148ba9
      Eric Paris authored
      inotify drops events if the last event on the queue is the same as the
      current event.  But it does 2 things wrong.  First it is comparing old->inode
      with new->inode.  But after an event if put on the queue the ->inode is no
      longer allowed to be used.  It's possible between the last event and this new
      event the inode could be reused and we would falsely match the inode's memory
      address between two differing events.
      
      The second problem is that when a file is removed fsnotify is passed the
      negative dentry for the removed object rather than the postive dentry from
      immediately before the removal.  This mean the (broken) inotify tail drop code
      was matching the NULL ->inode of differing events.
      
      The fix is to check the file name which is stored with events when doing the
      tail drop instead of wrongly checking the address of the stored ->inode.
      Reported-by: default avatarScott James Remnant <scott@ubuntu.com>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      4a148ba9
  6. 11 Jun, 2009 5 commits
    • Eric Paris's avatar
      fsnotify: allow groups to add private data to events · e4aff117
      Eric Paris authored
      inotify needs per group information attached to events.  This patch allows
      groups to attach private information and implements a callback so that
      information can be freed when an event is being destroyed.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      e4aff117
    • Eric Paris's avatar
      fsnotify: add correlations between events · 47882c6f
      Eric Paris authored
      As part of the standard inotify events it includes a correlation cookie
      between two dentry move operations.  This patch includes the same behaviour
      in fsnotify events.  It is needed so that inotify userspace can be
      implemented on top of fsnotify.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      47882c6f
    • Eric Paris's avatar
      fsnotify: include pathnames with entries when possible · 62ffe5df
      Eric Paris authored
      When inotify wants to send events to a directory about a child it includes
      the name of the original file.  This patch collects that filename and makes
      it available for notification.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      62ffe5df
    • Eric Paris's avatar
      fsnotify: generic notification queue and waitq · a2d8bc6c
      Eric Paris authored
      inotify needs to do asyc notification in which event information is stored
      on a queue until the listener is ready to receive it.  This patch
      implements a generic notification queue for inotify (and later fanotify) to
      store events to be sent at a later time.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      a2d8bc6c
    • Eric Paris's avatar
      fsnotify: unified filesystem notification backend · 90586523
      Eric Paris authored
      fsnotify is a backend for filesystem notification.  fsnotify does
      not provide any userspace interface but does provide the basis
      needed for other notification schemes such as dnotify.  fsnotify
      can be extended to be the backend for inotify or the upcoming
      fanotify.  fsnotify provides a mechanism for "groups" to register for
      some set of filesystem events and to then deliver those events to
      those groups for processing.
      
      fsnotify has a number of benefits, the first being actually shrinking the size
      of an inode.  Before fsnotify to support both dnotify and inotify an inode had
      
              unsigned long           i_dnotify_mask; /* Directory notify events */
              struct dnotify_struct   *i_dnotify; /* for directory notifications */
              struct list_head        inotify_watches; /* watches on this inode */
              struct mutex            inotify_mutex;  /* protects the watches list
      
      But with fsnotify this same functionallity (and more) is done with just
      
              __u32                   i_fsnotify_mask; /* all events for this inode */
              struct hlist_head       i_fsnotify_mark_entries; /* marks on this inode */
      
      That's right, inotify, dnotify, and fanotify all in 64 bits.  We used that
      much space just in inotify_watches alone, before this patch set.
      
      fsnotify object lifetime and locking is MUCH better than what we have today.
      inotify locking is incredibly complex.  See 8f7b0ba1 as an example of
      what's been busted since inception.  inotify needs to know internal semantics
      of superblock destruction and unmounting to function.  The inode pinning and
      vfs contortions are horrible.
      
      no fsnotify implementers do allocation under locks.  This means things like
      f04b30de which (due to an overabundance of caution) changes GFP_KERNEL to
      GFP_NOFS can be reverted.  There are no longer any allocation rules when using
      or implementing your own fsnotify listener.
      
      fsnotify paves the way for fanotify.  In brief fanotify is a notification
      mechanism that delivers the lisener both an 'event' and an open file descriptor
      to the object in question.  This means that fanotify is pathname agnostic.
      Some on lkml may not care for the original companies or users that pushed for
      TALPA, but fanotify was designed with flexibility and input for other users in
      mind.  The readahead group expressed interest in fanotify as it could be used
      to profile disk access on boot without breaking the audit system.  The desktop
      search groups have also expressed interest in fanotify as it solves a number
      of the race conditions and problems present with managing inotify when more
      than a limited number of specific files are of interest.  fanotify can provide
      for a userspace access control system which makes it a clean interface for AV
      vendors to hook without trying to do binary patching on the syscall table,
      LSM, and everywhere else they do their things today.  With this patch series
      fanotify can be implemented in less than 1200 lines of easy to review code.
      Almost all of which is the socket based user interface.
      
      This patch series builds fsnotify to the point that it can implement
      dnotify and inotify_user.  Patches exist and will be sent soon after
      acceptance to finish the in kernel inotify conversion (audit) and implement
      fanotify.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      90586523