1. 18 Oct, 2009 1 commit
  2. 17 Aug, 2009 2 commits
  3. 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>
    • 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
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
    • 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>
  4. 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>
    • 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>
    • 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>
    • 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>
    • 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
       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
      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>