1. 04 9月, 2009 7 次提交
  2. 29 8月, 2009 21 次提交
  3. 28 8月, 2009 9 次提交
  4. 27 8月, 2009 3 次提交
    • E
      inotify: Ensure we alwasy write the terminating NULL. · 0db501bd
      Eric W. Biederman 提交于
      Before the rewrite copy_event_to_user always wrote a terqminating '\0'
      byte to user space after the filename.  Since the rewrite that
      terminating byte was skipped if your filename is exactly a multiple of
      event_size.  Ouch!
      
      So add one byte to name_size before we round up and use clear_user to
      set userspace to zero like /dev/zero does instead of copying the
      strange nul_inotify_event.  I can't quite convince myself len_to_zero
      will never exceed 16 and even if it doesn't clear_user should be more
      efficient and a more accurate reflection of what the code is trying to
      do.
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      0db501bd
    • E
      inotify: fix locking around inotify watching in the idr · dead537d
      Eric Paris 提交于
      The are races around the idr storage of inotify watches.  It's possible
      that a watch could be found from sys_inotify_rm_watch() in the idr, but it
      could be removed from the idr before that code does it's removal.  Move the
      locking and the refcnt'ing so that these have to happen atomically.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      dead537d
    • E
      inotify: do not BUG on idr entries at inotify destruction · cf437426
      Eric Paris 提交于
      If an inotify watch is left in the idr when an fsnotify group is destroyed
      this will lead to a BUG.  This is not a dangerous situation and really
      indicates a programming bug and leak of memory.  This patch changes it to
      use a WARN and a printk rather than killing people's boxes.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      cf437426