1. 14 11月, 2014 1 次提交
  2. 10 10月, 2014 1 次提交
  3. 28 7月, 2010 10 次提交
    • E
      fsnotify: remove global fsnotify groups lists · 02436668
      Eric Paris 提交于
      The global fsnotify groups lists were invented as a way to increase the
      performance of fsnotify by shortcutting events which were not interesting.
      With the changes to walk the object lists rather than global groups lists
      these shortcuts are not useful.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      02436668
    • E
      fsnotify: remove the global masks · 03930979
      Eric Paris 提交于
      Because we walk the object->fsnotify_marks list instead of the global
      fsnotify groups list we don't need the fsnotify_inode_mask and
      fsnotify_vfsmount_mask as these were simply shortcuts in fsnotify() for
      performance.  They are now extra checks, rip them out.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      03930979
    • E
      fsnotify: srcu to protect read side of inode and vfsmount locks · 75c1be48
      Eric Paris 提交于
      Currently reading the inode->i_fsnotify_marks or
      vfsmount->mnt_fsnotify_marks lists are protected by a spinlock on both the
      read and the write side.  This patch protects the read side of those lists
      with a new single srcu.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      75c1be48
    • E
      fsnotify: allow marks to not pin inodes in core · 90b1e7a5
      Eric Paris 提交于
      inotify marks must pin inodes in core.  dnotify doesn't technically need to
      since they are closed when the directory is closed.  fanotify also need to
      pin inodes in core as it works today.  But the next step is to introduce
      the concept of 'ignored masks' which is actually a mask of events for an
      inode of no interest.  I claim that these should be liberally sent to the
      kernel and should not pin the inode in core.  If the inode is brought back
      in the listener will get an event it may have thought excluded, but this is
      not a serious situation and one any listener should deal with.
      
      This patch lays the ground work for non-pinning inode marks by using lazy
      inode pinning.  We do not pin a mark until it has a non-zero mask entry.  If a
      listener new sets a mask we never pin the inode.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      90b1e7a5
    • A
      fsnotify: Infrastructure for per-mount watches · ca9c726e
      Andreas Gruenbacher 提交于
      Per-mount watches allow groups to listen to fsnotify events on an entire
      mount.  This patch simply adds and initializes the fields needed in the
      vfsmount struct to make this happen.
      Signed-off-by: NAndreas Gruenbacher <agruen@suse.de>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      ca9c726e
    • E
      fsnotify: vfsmount marks generic functions · 0d48b7f0
      Eric Paris 提交于
      Much like inode-mark.c has all of the code dealing with marks on inodes
      this patch adds a vfsmount-mark.c which has similar code but is intended
      for marks on vfsmounts.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      0d48b7f0
    • E
      fsnotify: split generic and inode specific mark code · 5444e298
      Eric Paris 提交于
      currently all marking is done by functions in inode-mark.c.  Some of this
      is pretty generic and should be instead done in a generic function and we
      should only put the inode specific code in inode-mark.c
      Signed-off-by: NEric Paris <eparis@redhat.com>
      5444e298
    • E
      fsnotify: mount point listeners list and global mask · 7131485a
      Eric Paris 提交于
      currently all of the notification systems implemented select which inodes
      they care about and receive messages only about those inodes (or the
      children of those inodes.)  This patch begins to flesh out fsnotify support
      for the concept of listeners that want to hear notification for an inode
      accessed below a given monut point.  This patch implements a second list
      of fsnotify groups to hold these types of groups and a second global mask
      to hold the events of interest for this type of group.
      
      The reason we want a second group list and mask is because the inode based
      notification should_send_event support which makes each group look for a mark
      on the given inode.  With one nfsmount listener that means that every group would
      have to take the inode->i_lock, look for their mark, not find one, and return
      for every operation.   By seperating vfsmount from inode listeners only when
      there is a inode listener will the inode groups have to look for their
      mark and take the inode lock.  vfsmount listeners will have to grab the lock and
      look for a mark but there should be fewer of them, and one vfsmount listener
      won't cause the i_lock to be grabbed and released for every fsnotify group
      on every io operation.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      7131485a
    • E
      fsnotify: add groups to fsnotify_inode_groups when registering inode watch · 4ca76352
      Eric Paris 提交于
      Currently all fsnotify groups are added immediately to the
      fsnotify_inode_groups list upon creation.  This means, even groups with no
      watches (common for audit) will be on the global tracking list and will
      get checked for every event.  This patch adds groups to the global list on
      when the first inode mark is added to the group.
      Signed-of-by: NEric Paris <eparis@redhat.com>
      4ca76352
    • E
      fsnotify: rename fsnotify_groups to fsnotify_inode_groups · 19c2a0e1
      Eric Paris 提交于
      Simple renaming patch.  fsnotify is about to support mount point listeners
      so I am renaming fsnotify_groups and fsnotify_mask to indicate these are lists
      used only for groups which have watches on inodes.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      19c2a0e1
  4. 12 6月, 2009 4 次提交
    • E
      fsnotify: generic notification queue and waitq · a2d8bc6c
      Eric Paris 提交于
      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: NEric Paris <eparis@redhat.com>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      a2d8bc6c
    • E
      fsnotify: parent event notification · c28f7e56
      Eric Paris 提交于
      inotify and dnotify both use a similar parent notification mechanism.  We
      add a generic parent notification mechanism to fsnotify for both of these
      to use.  This new machanism also adds the dentry flag optimization which
      exists for inotify to dnotify.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      c28f7e56
    • E
      fsnotify: add marks to inodes so groups can interpret how to handle those inodes · 3be25f49
      Eric Paris 提交于
      This patch creates a way for fsnotify groups to attach marks to inodes.
      These marks have little meaning to the generic fsnotify infrastructure
      and thus their meaning should be interpreted by the group that attached
      them to the inode's list.
      
      dnotify and inotify  will make use of these markings to indicate which
      inodes are of interest to their respective groups.  But this implementation
      has the useful property that in the future other listeners could actually
      use the marks for the exact opposite reason, aka to indicate which inodes
      it had NO interest in.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      3be25f49
    • E
      fsnotify: unified filesystem notification backend · 90586523
      Eric Paris 提交于
      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: NEric Paris <eparis@redhat.com>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      90586523