1. 29 10月, 2010 15 次提交
    • E
      fsnotify: rename FS_IN_ISDIR to FS_ISDIR · b29866aa
      Eric Paris 提交于
      The _IN_ in the naming is reserved for flags only used by inotify.  Since I
      am about to use this flag for fanotify rename it to be generic like the
      rest.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      b29866aa
    • E
      fanotify: limit number of listeners per user · 4afeff85
      Eric Paris 提交于
      fanotify currently has no limit on the number of listeners a given user can
      have open.  This patch limits the total number of listeners per user to
      128.  This is the same as the inotify default limit.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      4afeff85
    • E
      fanotify: allow userspace to override max marks · ac7e22dc
      Eric Paris 提交于
      Some fanotify groups, especially those like AV scanners, will need to place
      lots of marks, particularly ignore marks.  Since ignore marks do not pin
      inodes in cache and are cleared if the inode is removed from core (usually
      under memory pressure) we expose an interface for listeners, with
      CAP_SYS_ADMIN, to override the maximum number of marks and be allowed to
      set and 'unlimited' number of marks.  Programs which make use of this
      feature will be able to OOM a machine.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      ac7e22dc
    • E
      fanotify: limit the number of marks in a single fanotify group · e7099d8a
      Eric Paris 提交于
      There is currently no limit on the number of marks a given fanotify group
      can have.  Since fanotify is gated on CAP_SYS_ADMIN this was not seen as
      a serious DoS threat.  This patch implements a default of 8192, the same as
      inotify to work towards removing the CAP_SYS_ADMIN gating and eliminating
      the default DoS'able status.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      e7099d8a
    • E
      fanotify: allow userspace to override max queue depth · 5dd03f55
      Eric Paris 提交于
      fanotify has a defualt max queue depth.  This patch allows processes which
      explicitly request it to have an 'unlimited' queue depth.  These processes
      need to be very careful to make sure they cannot fall far enough behind
      that they OOM the box.  Thus this flag is gated on CAP_SYS_ADMIN.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      5dd03f55
    • E
      fsnotify: implement a default maximum queue depth · 2529a0df
      Eric Paris 提交于
      Currently fanotify has no maximum queue depth.  Since fanotify is
      CAP_SYS_ADMIN only this does not pose a normal user DoS issue, but it
      certianly is possible that an fanotify listener which can't keep up could
      OOM the box.  This patch implements a default 16k depth.  This is the same
      default depth used by inotify, but given fanotify's better queue merging in
      many situations this queue will contain many additional useful events by
      comparison.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      2529a0df
    • E
      fanotify: allow userspace to flush all marks · bbf2aba5
      Eric Paris 提交于
      fanotify is supposed to be able to flush all marks.  This is mostly useful
      for the AV community to flush all cached decisions on a security policy
      change.  This functionality has existed in the kernel but wasn't correctly
      exposed to userspace.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      bbf2aba5
    • E
      fsnotify: call fsnotify_parent in perm events · 52420392
      Eric Paris 提交于
      fsnotify perm events do not call fsnotify parent.  That means you cannot
      register a perm event on a directory and enforce permissions on all inodes in
      that directory.  This patch fixes that situation.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      52420392
    • E
      fsnotify: correctly handle return codes from listeners · ff8bcbd0
      Eric Paris 提交于
      When fsnotify groups return errors they are ignored.  For permissions
      events these should be passed back up the stack, but for most events these
      should continue to be ignored.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      ff8bcbd0
    • E
      fanotify: use __aligned_u64 in fanotify userspace metadata · 28682019
      Eric Paris 提交于
      Currently the userspace struct exposed by fanotify uses
      __attribute__((packed)) to make sure that alignment works on multiarch
      platforms.  Since this causes a severe performance penalty on some
      platforms we are going to switch to using explicit alignment notation on
      the 64bit values so we don't have to use 'packed'
      Signed-off-by: NEric Paris <eparis@redhat.com>
      28682019
    • E
      fanotify: implement fanotify listener ordering · 4231a235
      Eric Paris 提交于
      The fanotify listeners needs to be able to specify what types of operations
      they are going to perform so they can be ordered appropriately between other
      listeners doing other types of operations.  They need this to be able to make
      sure that things like hierarchichal storage managers will get access to inodes
      before processes which need the data.  This patch defines 3 possible uses
      which groups must indicate in the fanotify_init() flags.
      
      FAN_CLASS_PRE_CONTENT
      FAN_CLASS_CONTENT
      FAN_CLASS_NOTIF
      
      Groups will receive notification in that order.  The order between 2 groups in
      the same class is undeterministic.
      
      FAN_CLASS_PRE_CONTENT is intended to be used by listeners which need access to
      the inode before they are certain that the inode contains it's final data.  A
      hierarchical storage manager should choose to use this class.
      
      FAN_CLASS_CONTENT is intended to be used by listeners which need access to the
      inode after it contains its intended contents.  This would be the appropriate
      level for an AV solution or document control system.
      
      FAN_CLASS_NOTIF is intended for normal async notification about access, much the
      same as inotify and dnotify.  Syncronous permissions events are not permitted
      at this class.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      4231a235
    • E
      fsnotify: implement ordering between notifiers · 6ad2d4e3
      Eric Paris 提交于
      fanotify needs to be able to specify that some groups get events before
      others.  They use this idea to make sure that a hierarchical storage
      manager gets access to files before programs which actually use them.  This
      is purely infrastructure.  Everything will have a priority of 0, but the
      infrastructure will exist for it to be non-zero.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      6ad2d4e3
    • E
      fanotify: allow fanotify to be built · 9343919c
      Eric Paris 提交于
      We disabled the ability to build fanotify in commit 7c534773.
      This reverts that commit and allows people to build fanotify.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      9343919c
    • F
      mmu_notifier.h: fix comment spelling · e732ff70
      Figo.zhang 提交于
      Signed-off-by: NFigo.zhang <figo1802@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e732ff70
    • I
      Fix compile brekage with !CONFIG_BLOCK · b31d42a5
      Ingo Molnar 提交于
      Today's git tree fails to build on !CONFIG_BLOCK, due to upstream commit
      367a51a3 ("fs: Add FITRIM ioctl"):
      
       include/linux/fs.h:36: error: expected specifier-qualifier-list before ‘uint64_t’
       include/linux/fs.h:36: error: expected specifier-qualifier-list before ‘uint64_t’
       include/linux/fs.h:36: error: expected specifier-qualifier-list before ‘uint64_t’
      
      The commit adds uint64_t type usage to fs.h, but linux/types.h is not included
      explicitly - it's only included implicitly via linux/blk_types.h, and there only if
      CONFIG_BLOCK is enabled.
      
      Add the explicit #include to fix this.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b31d42a5
  2. 28 10月, 2010 25 次提交