1. 31 Oct, 2005 1 commit
    • Eric W. Biederman's avatar
      [PATCH] Don't uselessly export task_struct to userspace in core dumps · a9289728
      Eric W. Biederman authored
      
      
      task_struct is an internal structure to the kernel with a lot of good
      information, that is probably interesting in core dumps.  However there is
      no way for user space to know what format that information is in making it
      useless.
      
      I grepped the GDB 6.3 source code and NT_TASKSTRUCT while defined is not
      used anywhere else.  So I would be surprised if anyone notices it is
      missing.
      
      In addition exporting kernel pointers to all the interesting kernel data
      structures sounds like the very definition of an information leak.  I
      haven't a clue what someone with evil intentions could do with that
      information, but in any attack against the kernel it looks like this is the
      perfect tool for aiming that attack.
      
      So since NT_TASKSTRUCT is useless as currently defined and is potentially
      dangerous, let's just not export it.
      
      (akpm: Daniel Jacobowitz <dan@debian.org> "would be amazed" if anything was
      using NT_TASKSTRUCT).
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a9289728
  2. 30 Oct, 2005 1 commit
  3. 11 Oct, 2005 1 commit
  4. 22 Jun, 2005 1 commit
    • Wolfgang Wander's avatar
      [PATCH] Avoiding mmap fragmentation · 1363c3cd
      Wolfgang Wander authored
      
      
      Ingo recently introduced a great speedup for allocating new mmaps using the
      free_area_cache pointer which boosts the specweb SSL benchmark by 4-5% and
      causes huge performance increases in thread creation.
      
      The downside of this patch is that it does lead to fragmentation in the
      mmap-ed areas (visible via /proc/self/maps), such that some applications
      that work fine under 2.4 kernels quickly run out of memory on any 2.6
      kernel.
      
      The problem is twofold:
      
        1) the free_area_cache is used to continue a search for memory where
           the last search ended.  Before the change new areas were always
           searched from the base address on.
      
           So now new small areas are cluttering holes of all sizes
           throughout the whole mmap-able region whereas before small holes
           tended to close holes near the base leaving holes far from the base
           large and available for larger requests.
      
        2) the free_area_cache also is set to the location of the last
           munmap-ed area so in scenarios where we allocate e.g.  five regions of
           1K each, then free regions 4 2 3 in this order the next request for 1K
           will be placed in the position of the old region 3, whereas before we
           appended it to the still active region 1, placing it at the location
           of the old region 2.  Before we had 1 free region of 2K, now we only
           get two free regions of 1K -> fragmentation.
      
      The patch addresses thes issues by introducing yet another cache descriptor
      cached_hole_size that contains the largest known hole size below the
      current free_area_cache.  If a new request comes in the size is compared
      against the cached_hole_size and if the request can be filled with a hole
      below free_area_cache the search is started from the base instead.
      
      The results look promising: Whereas 2.6.12-rc4 fragments quickly and my
      (earlier posted) leakme.c test program terminates after 50000+ iterations
      with 96 distinct and fragmented maps in /proc/self/maps it performs nicely
      (as expected) with thread creation, Ingo's test_str02 with 20000 threads
      requires 0.7s system time.
      
      Taking out Ingo's patch (un-patch available per request) by basically
      deleting all mentions of free_area_cache from the kernel and starting the
      search for new memory always at the respective bases we observe: leakme
      terminates successfully with 11 distinctive hardly fragmented areas in
      /proc/self/maps but thread creating is gringdingly slow: 30+s(!) system
      time for Ingo's test_str02 with 20000 threads.
      
      Now - drumroll ;-) the appended patch works fine with leakme: it ends with
      only 7 distinct areas in /proc/self/maps and also thread creation seems
      sufficiently fast with 0.71s for 20000 threads.
      Signed-off-by: default avatarWolfgang Wander <wwc@rentec.com>
      Credit-to: "Richard Purdie" <rpurdie@rpsys.net>
      Signed-off-by: default avatarKen Chen <kenneth.w.chen@intel.com>
      Acked-by: Ingo Molnar <mingo@elte.hu> (partly)
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1363c3cd
  5. 16 Jun, 2005 1 commit
  6. 17 May, 2005 1 commit
  7. 28 Apr, 2005 1 commit
  8. 16 Apr, 2005 2 commits
    • Benjamin Herrenschmidt's avatar
      [PATCH] ppc64: Improve mapping of vDSO · 547ee84c
      Benjamin Herrenschmidt authored
      
      
      This patch reworks the way the ppc64 is mapped in user memory by the kernel
      to make it more robust against possible collisions with executable
      segments.  Instead of just whacking a VMA at 1Mb, I now use
      get_unmapped_area() with a hint, and I moved the mapping of the vDSO to
      after the mapping of the various ELF segments and of the interpreter, so
      that conflicts get caught properly (it still has to be before
      create_elf_tables since the later will fill the AT_SYSINFO_EHDR with the
      proper address).
      
      While I was at it, I also changed the 32 and 64 bits vDSO's to link at
      their "natural" address of 1Mb instead of 0.  This is the address where
      they are normally mapped in absence of conflict.  By doing so, it should be
      possible to properly prelink one it's been verified to work on glibc.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      547ee84c
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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