1. 30 1月, 2008 1 次提交
  2. 08 11月, 2007 1 次提交
  3. 17 10月, 2007 1 次提交
  4. 26 9月, 2006 1 次提交
  5. 05 9月, 2005 1 次提交
    • S
      [PATCH] selinux: Reduce memory use by avtab · 782ebb99
      Stephen Smalley 提交于
      This patch improves memory use by SELinux by both reducing the avtab node
      size and reducing the number of avtab nodes.  The memory savings are
      substantial, e.g.  on a 64-bit system after boot, James Morris reported the
      following data for the targeted and strict policies:
      
                  #objs  objsize   kernmem
      Targeted:
        Before:  237888       40     9.1MB
        After:    19968       24     468KB
      
      Strict:
        Before:  571680       40   21.81MB
        After:   221052       24    5.06MB
      
      The improvement in memory use comes at a cost in the speed of security
      server computations of access vectors, but these computations are only
      required on AVC cache misses, and performance measurements by James Morris
      using a number of benchmarks have shown that the change does not cause any
      significant degradation.
      
      Note that a rebuilt policy via an updated policy toolchain
      (libsepol/checkpolicy) is required in order to gain the full benefits of
      this patch, although some memory savings benefits are immediately applied
      even to older policies (in particular, the reduction in avtab node size).
      Sources for the updated toolchain are presently available from the
      sourceforge CVS tree (http://sourceforge.net/cvs/?group_id=21266), and
      tarballs are available from http://www.flux.utah.edu/~sds.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      782ebb99
  6. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4