1. 21 Jul, 2009 5 commits
    • 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
    • Eric Paris's avatar
      fsnotify: use def_bool in kconfig instead of letting the user choose · 520dc2a5
      Eric Paris authored
      
      
      fsnotify doens't give the user anything.  If someone chooses inotify or
      dnotify it should build fsnotify, if they don't select one it shouldn't be
      built.  This patch changes fsnotify to be a def_bool=n and makes everything
      else select it.  Also fixes the issue people complained about on lwn where
      gdm hung because they didn't have inotify and they didn't get the inotify
      build option.....
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      520dc2a5
    • Eric Paris's avatar
      inotify: fix error paths in inotify_update_watch · 7e790dd5
      Eric Paris authored
      
      
      inotify_update_watch could leave things in a horrid state on a number of
      error paths.  We could try to remove idr entries that didn't exist, we
      could send an IN_IGNORED to userspace for watches that don't exist, and a
      bit of other stupidity.  Clean these up by doing the idr addition before we
      put the mark on the inode since we can clean that up on error and getting
      off the inode's mark list is hard.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      7e790dd5
    • Eric Paris's avatar
      inotify: do not leak inode marks in inotify_add_watch · 75fe2b26
      Eric Paris authored
      
      
      inotify_add_watch had a couple of problems.  The biggest being that if
      inotify_add_watch was called on the same inode twice (to update or change the
      event mask) a refence was taken on the original inode mark by
      fsnotify_find_mark_entry but was not being dropped at the end of the
      inotify_add_watch call.  Thus if inotify_rm_watch was called although the mark
      was removed from the inode, the refcnt wouldn't hit zero and we would leak
      memory.
      Reported-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      75fe2b26
    • Eric Paris's avatar
      inotify: drop user watch count when a watch is removed · 5549f7cd
      Eric Paris authored
      
      
      The inotify rewrite forgot to drop the inotify watch use cound when a watch
      was removed.  This means that a single inotify fd can only ever register a
      maximum of /proc/sys/fs/max_user_watches even if some of those had been
      freed.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      5549f7cd
  2. 20 Jul, 2009 10 commits
  3. 18 Jul, 2009 4 commits
  4. 17 Jul, 2009 21 commits