1. 08 Oct, 2016 2 commits
  2. 19 Sep, 2016 2 commits
  3. 07 Aug, 2014 2 commits
  4. 25 Feb, 2014 3 commits
    • Jan Kara's avatar
      fsnotify: Allocate overflow events with proper type · ff57cd58
      Jan Kara authored
      Commit 7053aee2 "fsnotify: do not share events between notification
      groups" used overflow event statically allocated in a group with the
      size of the generic notification event. This causes problems because
      some code looks at type specific parts of event structure and gets
      confused by a random data it sees there and causes crashes.
      Fix the problem by allocating overflow event with type corresponding to
      the group type so code cannot get confused.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
    • Jan Kara's avatar
      fanotify: Handle overflow in case of permission events · 482ef06c
      Jan Kara authored
      If the event queue overflows when we are handling permission event, we
      will never get response from userspace. So we must avoid waiting for it.
      Change fsnotify_add_notify_event() to return whether overflow has
      happened so that we can detect it in fanotify_handle_event() and act
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
    • Jan Kara's avatar
      fsnotify: Fix detection whether overflow event is queued · 2513190a
      Jan Kara authored
      Currently we didn't initialize event's list head when we removed it from
      the event list. Thus a detection whether overflow event is already
      queued wasn't working. Fix it by always initializing the list head when
      deleting event from a list.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
  5. 29 Jan, 2014 1 commit
  6. 22 Jan, 2014 1 commit
    • Jan Kara's avatar
      fsnotify: do not share events between notification groups · 7053aee2
      Jan Kara authored
      Currently fsnotify framework creates one event structure for each
      notification event and links this event into all interested notification
      groups.  This is done so that we save memory when several notification
      groups are interested in the event.  However the need for event
      structure shared between inotify & fanotify bloats the event structure
      so the result is often higher memory consumption.
      Another problem is that fsnotify framework keeps path references with
      outstanding events so that fanotify can return open file descriptors
      with its events.  This has the undesirable effect that filesystem cannot
      be unmounted while there are outstanding events - a regression for
      inotify compared to a situation before it was converted to fsnotify
      framework.  For fanotify this problem is hard to avoid and users of
      fanotify should kind of expect this behavior when they ask for file
      descriptors from notified files.
      This patch changes fsnotify and its users to create separate event
      structure for each group.  This allows for much simpler code (~400 lines
      removed by this patch) and also smaller event structures.  For example
      on 64-bit system original struct fsnotify_event consumes 120 bytes, plus
      additional space for file name, additional 24 bytes for second and each
      subsequent group linking the event, and additional 32 bytes for each
      inotify group for private data.  After the conversion inotify event
      consumes 48 bytes plus space for file name which is considerably less
      memory unless file names are long and there are several groups
      interested in the events (both of which are uncommon).  Fanotify event
      fits in 56 bytes after the conversion (fanotify doesn't care about file
      names so its events don't have to have it allocated).  A win unless
      there are four or more fanotify groups interested in the event.
      The conversion also solves the problem with unmount when only inotify is
      used as we don't have to grab path references for inotify events.
      [hughd@google.com: fanotify: fix corruption preventing startup]
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  7. 11 Dec, 2012 1 commit
  8. 19 Nov, 2012 1 commit
  9. 23 Mar, 2012 1 commit
  10. 26 Jul, 2011 1 commit
  11. 12 Aug, 2010 1 commit
  12. 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
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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
    • 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>
    • 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>
    • 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>
    • 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
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
    • 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>
    • 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>
    • 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>
    • 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>
  13. 18 Oct, 2009 1 commit
  14. 17 Aug, 2009 2 commits
  15. 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>
  16. 11 Jun, 2009 4 commits