1. 19 9月, 2007 1 次提交
  2. 14 6月, 2007 1 次提交
  3. 09 5月, 2007 1 次提交
  4. 13 2月, 2007 1 次提交
    • B
      [POWERPC] Fix vDSO page count calculation · 7ac9a137
      Benjamin Herrenschmidt 提交于
      The recent vDSO consolidation patches broke powerpc due to a mistake
      in the definition of MAXPAGES constants. This fixes it by moving to
      a dynamically allocated array of pages instead as I don't like much
      hard coded size limits. Also move the vdso initialisation to an initcall
      since it doesn't really need to be done -that- early.
      
      Applogies for not catching the breakage earlier, Roland _did_ CC me on
      his patches a while ago, I got busy with other things and forgot to test
      them.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7ac9a137
  5. 10 2月, 2007 1 次提交
  6. 27 1月, 2007 1 次提交
  7. 08 12月, 2006 1 次提交
  8. 25 10月, 2006 1 次提交
    • B
      [POWERPC] Support feature fixups in vdso's · 0909c8c2
      Benjamin Herrenschmidt 提交于
      This patch reworks the feature fixup mecanism so vdso's can be fixed up.
      The main issue was that the construct:
      
              .long   label  (or .llong on 64 bits)
      
      will not work in the case of a shared library like the vdso. It will
      generate an empty placeholder in the fixup table along with a reloc,
      which is not something we can deal with in the vdso.
      
      The idea here (thanks Alan Modra !) is to instead use something like:
      
      1:
              .long   label - 1b
      
      That is, the feature fixup tables no longer contain addresses of bits of
      code to patch, but offsets of such code from the fixup table entry
      itself. That is properly resolved by ld when building the .so's. I've
      modified the fixup mecanism generically to use that method for the rest
      of the kernel as well.
      
      Another trick is that the 32 bits vDSO included in the 64 bits kernel
      need to have a table in the 64 bits format. However, gas does not
      support 32 bits code with a statement of the form:
      
              .llong  label - 1b  (Or even just .llong label)
      
      That is, it cannot emit the right fixup/relocation for the linker to use
      to assign a 32 bits address to an .llong field. Thus, in the specific
      case of the 32 bits vdso built as part of the 64 bits kernel, we are
      using a modified macro that generates:
      
              .long   0xffffffff
              .llong  label - 1b
      
      Note that is assumes that the value is negative which is enforced by
      the .lds (those offsets are always negative as the .text is always
      before the fixup table and gas doesn't support emiting the reloc the
      other way around).
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0909c8c2
  9. 01 7月, 2006 1 次提交
  10. 09 6月, 2006 1 次提交
  11. 28 3月, 2006 1 次提交
  12. 01 3月, 2006 1 次提交
  13. 10 2月, 2006 1 次提交
  14. 29 11月, 2005 1 次提交
    • L
      mm: re-architect the VM_UNPAGED logic · 6aab341e
      Linus Torvalds 提交于
      This replaces the (in my opinion horrible) VM_UNMAPPED logic with very
      explicit support for a "remapped page range" aka VM_PFNMAP.  It allows a
      VM area to contain an arbitrary range of page table entries that the VM
      never touches, and never considers to be normal pages.
      
      Any user of "remap_pfn_range()" automatically gets this new
      functionality, and doesn't even have to mark the pages reserved or
      indeed mark them any other way.  It just works.  As a side effect, doing
      mmap() on /dev/mem works for arbitrary ranges.
      
      Sparc update from David in the next commit.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6aab341e
  15. 23 11月, 2005 1 次提交
    • H
      [PATCH] unpaged: VM_UNPAGED · 0b14c179
      Hugh Dickins 提交于
      Although we tend to associate VM_RESERVED with remap_pfn_range, quite a few
      drivers set VM_RESERVED on areas which are then populated by nopage.  The
      PageReserved removal in 2.6.15-rc1 changed VM_RESERVED not to free pages in
      zap_pte_range, without changing those drivers not to set it: so their pages
      just leak away.
      
      Let's not change miscellaneous drivers now: introduce VM_UNPAGED at the core,
      to flag the special areas where the ptes may have no struct page, or if they
      have then it's not to be touched.  Replace most instances of VM_RESERVED in
      core mm by VM_UNPAGED.  Force it on in remap_pfn_range, and the sparc and
      sparc64 io_remap_pfn_range.
      
      Revert addition of VM_RESERVED to powerpc vdso, it's not needed there.  Is it
      needed anywhere?  It still governs the mm->reserved_vm statistic, and special
      vmas not to be merged, and areas not to be core dumped; but could probably be
      eliminated later (the drivers are probably specifying it because in 2.4 it
      kept swapout off the vma, but in 2.6 we work from the LRU, which these pages
      don't get on).
      
      Use the VM_SHM slot for VM_UNPAGED, and define VM_SHM to 0: it serves no
      purpose whatsoever, and should be removed from drivers when we clean up.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Acked-by: NWilliam Irwin <wli@holomorphy.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0b14c179
  16. 11 11月, 2005 1 次提交
    • B
      [PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel · a7f290da
      Benjamin Herrenschmidt 提交于
      This patch moves the vdso's to arch/powerpc, adds support for the 32
      bits vdso to the 32 bits kernel, rename systemcfg (finally !), and adds
      some new (still untested) routines to both vdso's: clock_gettime() with
      support for CLOCK_REALTIME and CLOCK_MONOTONIC, clock_getres() (same
      clocks) and get_tbfreq() for glibc to retreive the timebase frequency.
      
      Tom,Steve: The implementation of get_tbfreq() I've done for 32 bits
      returns a long long (r3, r4) not a long. This is such that if we ever
      add support for >4Ghz timebases on ppc32, the userland interface won't
      have to change.
      
      I have tested gettimeofday() using some glibc patches in both ppc32 and
      ppc64 kernels using 32 bits userland (I haven't had a chance to test a
      64 bits userland yet, but the implementation didn't change and was
      tested earlier). I haven't tested yet the new functions.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a7f290da
  17. 10 11月, 2005 1 次提交
  18. 30 10月, 2005 1 次提交
    • N
      [PATCH] core remove PageReserved · b5810039
      Nick Piggin 提交于
      Remove PageReserved() calls from core code by tightening VM_RESERVED
      handling in mm/ to cover PageReserved functionality.
      
      PageReserved special casing is removed from get_page and put_page.
      
      All setting and clearing of PageReserved is retained, and it is now flagged
      in the page_alloc checks to help ensure we don't introduce any refcount
      based freeing of Reserved pages.
      
      MAP_PRIVATE, PROT_WRITE of VM_RESERVED regions is tentatively being
      deprecated.  We never completely handled it correctly anyway, and is be
      reintroduced in future if required (Hugh has a proof of concept).
      
      Once PageReserved() calls are removed from kernel/power/swsusp.c, and all
      arch/ and driver code, the Set and Clear calls, and the PG_reserved bit can
      be trivially removed.
      
      Last real user of PageReserved is swsusp, which uses PageReserved to
      determine whether a struct page points to valid memory or not.  This still
      needs to be addressed (a generic page_is_ram() should work).
      
      A last caveat: the ZERO_PAGE is now refcounted and managed with rmap (and
      thus mapcounted and count towards shared rss).  These writes to the struct
      page could cause excessive cacheline bouncing on big systems.  There are a
      number of ways this could be addressed if it is an issue.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      
      Refcount bug fix for filemap_xip.c
      Signed-off-by: NCarsten Otte <cotte@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b5810039
  19. 15 9月, 2005 1 次提交
    • H
      [PATCH] error path in setup_arg_pages() misses vm_unacct_memory() · 2fd4ef85
      Hugh Dickins 提交于
      Pavel Emelianov and Kirill Korotaev observe that fs and arch users of
      security_vm_enough_memory tend to forget to vm_unacct_memory when a
      failure occurs further down (typically in setup_arg_pages variants).
      
      These are all users of insert_vm_struct, and that reservation will only
      be unaccounted on exit if the vma is marked VM_ACCOUNT: which in some
      cases it is (hidden inside VM_STACK_FLAGS) and in some cases it isn't.
      
      So x86_64 32-bit and ppc64 vDSO ELFs have been leaking memory into
      Committed_AS each time they're run.  But don't add VM_ACCOUNT to them,
      it's inappropriate to reserve against the very unlikely case that gdb
      be used to COW a vDSO page - we ought to do something about that in
      do_wp_page, but there are yet other inconsistencies to be resolved.
      
      The safe and economical way to fix this is to let insert_vm_struct do
      the security_vm_enough_memory check when it finds VM_ACCOUNT is set.
      
      And the MIPS irix_brk has been calling security_vm_enough_memory before
      calling do_brk which repeats it, doubly accounting and so also leaking.
      Remove that, and all the fs and arch calls to security_vm_enough_memory:
      give it a less misleading name later on.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-Off-By: NKirill Korotaev <dev@sw.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2fd4ef85
  20. 17 4月, 2005 2 次提交
    • B
      [PATCH] ppc64: Improve mapping of vDSO · 547ee84c
      Benjamin Herrenschmidt 提交于
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      547ee84c
    • 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