Skip to content

L
linux
Switch branch/tag
  1. 26 Oct, 2010 6 commits
    • Eric Paris's avatar
      IMA: use i_writecount rather than a private counter · b9593d30
      Eric Paris authored 
      IMA tracks the number of struct files which are holding a given inode
readonly and the number which are holding the inode write or r/w.  It
needs this information so when a new reader or writer comes in it can
tell if this new file will be able to invalidate results it already made
about existing files.

aka if a task is holding a struct file open RO, IMA measured the file
and recorded those measurements and then a task opens the file RW IMA
needs to note in the logs that the old measurement may not be correct.
It's called a "Time of Measure Time of Use" (ToMToU) issue.  The same is
true is a RO file is opened to an inode which has an open writer.  We
cannot, with any validity, measure the file in question since it could
be changing.

This patch attempts to use the i_writecount field to track writers.  The
i_writecount field actually embeds more information in it's value than
IMA needs but it should work for our purposes and allow us to shrink the
struct inode even more.
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
Acked-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b9593d30
    • Eric Paris's avatar
      IMA: use inode->i_lock to protect read and write counters · ad16ad00
      Eric Paris authored 
      Currently IMA used the iint->mutex to protect the i_readcount and
i_writecount.  This patch uses the inode->i_lock since we are going to
start using in inode objects and that is the most appropriate lock.
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
Acked-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ad16ad00
    • Eric Paris's avatar
      IMA: convert internal flags from long to char · 15aac676
      Eric Paris authored 
      The IMA flags is an unsigned long but there is only 1 flag defined.
Lets save a little space and make it a char.  This packs nicely next to
the array of u8's.
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
Acked-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      15aac676
    • Eric Paris's avatar
      IMA: use unsigned int instead of long for counters · 497f3233
      Eric Paris authored 
      Currently IMA uses 2 longs in struct inode.  To save space (and as it
seems impossible to overflow 32 bits) we switch these to unsigned int.
The switch to unsigned does require slightly different checks for
underflow, but it isn't complex.
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
Acked-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      497f3233
    • Eric Paris's avatar
      IMA: drop the inode opencount since it isn't needed for operation · b575156d
      Eric Paris authored 
      The opencount was used to help debugging to make sure that everything
which created a struct file also correctly made the IMA calls.  Since we
moved all of that into the VFS this isn't as necessary.  We should be
able to get the same amount of debugging out of just the reader and
write count.
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
Acked-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b575156d
    • Eric Paris's avatar
      IMA: use rbtree instead of radix tree for inode information cache · 85491641
      Eric Paris authored 
      The IMA code needs to store the number of tasks which have an open fd
granting permission to write a file even when IMA is not in use.  It
needs this information in order to be enabled at a later point in time
without losing it's integrity garantees.

At the moment that means we store a little bit of data about every inode
in a cache.  We use a radix tree key'd on the inode's memory address.
Dave Chinner pointed out that a radix tree is a terrible data structure
for such a sparse key space.  This patch switches to using an rbtree
which should be more efficient.

Bug report from Dave:

 "I just noticed that slabtop was reporting an awfully high usage of
  radix tree nodes:

   OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
  4200331 2778082  66%    0.55K 144839       29   2317424K radix_tree_node
  2321500 2060290  88%    1.00K  72581       32   2322592K xfs_inode
  2235648 2069791  92%    0.12K  69864       32    279456K iint_cache

  That is, 2.7M radix tree nodes are allocated, and the cache itself is
  consuming 2.3GB of RAM.  I know that the XFS inodei caches are indexed
  by radix tree node, but for 2 million cached inodes that would mean a
  density of 1 inode per radix tree node, which for a system with 16M
  inodes in the filsystems is an impossibly low density.  The worst I've
  seen in a production system like kernel.org is about 20-25% density,
  which would mean about 150-200k radix tree nodes for that many inodes.
  So it's not the inode cache.

  So I looked up what the iint_cache was.  It appears to used for
  storing per-inode IMA information, and uses a radix tree for indexing.
  It uses the *address* of the struct inode as the indexing key.  That
  means the key space is extremely sparse - for XFS the struct inode
  addresses are approximately 1000 bytes apart, which means the closest
  the radix tree index keys get is ~1000.  Which means that there is a
  single entry per radix tree leaf node, so the radix tree is using
  roughly 550 bytes for every 120byte structure being cached.  For the
  above example, it's probably wasting close to 1GB of RAM...."
Reported-by: default avatarDave Chinner <david@fromorbit.com>
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
Acked-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      85491641
  3. 20 Oct, 2010 5 commits
  5. 19 Oct, 2010 7 commits
  7. 18 Oct, 2010 18 commits
  9. 17 Oct, 2010 4 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7