1. 08 6月, 2016 1 次提交
  2. 13 5月, 2016 1 次提交
  3. 05 4月, 2016 1 次提交
    • K
      mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros · 09cbfeaf
      Kirill A. Shutemov 提交于
      PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
      ago with promise that one day it will be possible to implement page
      cache with bigger chunks than PAGE_SIZE.
      
      This promise never materialized.  And unlikely will.
      
      We have many places where PAGE_CACHE_SIZE assumed to be equal to
      PAGE_SIZE.  And it's constant source of confusion on whether
      PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
      especially on the border between fs and mm.
      
      Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
      breakage to be doable.
      
      Let's stop pretending that pages in page cache are special.  They are
      not.
      
      The changes are pretty straight-forward:
      
       - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
      
       - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
      
       - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
      
       - page_cache_get() -> get_page();
      
       - page_cache_release() -> put_page();
      
      This patch contains automated changes generated with coccinelle using
      script below.  For some reason, coccinelle doesn't patch header files.
      I've called spatch for them manually.
      
      The only adjustment after coccinelle is revert of changes to
      PAGE_CAHCE_ALIGN definition: we are going to drop it later.
      
      There are few places in the code where coccinelle didn't reach.  I'll
      fix them manually in a separate patch.  Comments and documentation also
      will be addressed with the separate patch.
      
      virtual patch
      
      @@
      expression E;
      @@
      - E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
      + E
      
      @@
      expression E;
      @@
      - E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
      + E
      
      @@
      @@
      - PAGE_CACHE_SHIFT
      + PAGE_SHIFT
      
      @@
      @@
      - PAGE_CACHE_SIZE
      + PAGE_SIZE
      
      @@
      @@
      - PAGE_CACHE_MASK
      + PAGE_MASK
      
      @@
      expression E;
      @@
      - PAGE_CACHE_ALIGN(E)
      + PAGE_ALIGN(E)
      
      @@
      expression E;
      @@
      - page_cache_get(E)
      + get_page(E)
      
      @@
      expression E;
      @@
      - page_cache_release(E)
      + put_page(E)
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      09cbfeaf
  4. 10 11月, 2015 2 次提交
    • R
      fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries · 1bde925d
      Rich Felker 提交于
      The ELF binary loader in binfmt_elf.c requires an MMU, making it
      impossible to use regular ELF binaries on NOMMU archs.  However, the FDPIC
      ELF loader in binfmt_elf_fdpic.c is fully capable as a loader for plain
      ELF, which requires constant displacements between LOAD segments, since it
      already supports FDPIC ELF files flagged as needing constant displacement.
      
      This patch adjusts the FDPIC ELF loader to accept non-FDPIC ELF files on
      NOMMU archs.  They are treated identically to FDPIC ELF files with the
      constant-displacement flag bit set, except for personality, which must
      match the ABI of the program being loaded; the PER_LINUX_FDPIC personality
      controls how the kernel interprets function pointers passed to sigaction.
      
      Files that do not set a stack size requirement explicitly are given a
      default stack size (matching the amount of committed stack the normal ELF
      loader for MMU archs would give them) rather than being rejected; this is
      necessary because plain ELF files generally do not declare stack
      requirements in theit program headers.
      
      Only ET_DYN (PIE) format ELF files are supported, since loading at a fixed
      virtual address is not possible on NOMMU.
      
      This patch was developed and tested on J2 (SH2-compatible) but should
      be usable immediately on all archs where binfmt_elf_fdpic is
      available. Moreover, by providing dummy definitions of the
      elf_check_fdpic() and elf_check_const_displacement() macros for archs
      which lack an FDPIC ABI, it should be possible to enable building of
      binfmt_elf_fdpic on all other NOMMU archs and thereby give them ELF
      binary support, but I have not yet tested this.
      
      The motivation for using binfmt_elf_fdpic.c rather than adapting
      binfmt_elf.c to NOMMU is that the former already has all the necessary
      code to work properly on NOMMU and has already received widespread
      real-world use and testing. I hope this is not controversial.
      
      I'm not really happy with having to unset the FDPIC_FUNCPTRS
      personality bit when loading non-FDPIC ELF. This bit should really
      reset automatically on execve, since otherwise, executing non-ELF
      binaries (e.g. bFLT) from an FDPIC process will leave the personality
      in the wrong state and severely break signal handling. But that's a
      separate, existing bug and I don't know the right place to fix it.
      Signed-off-by: NRich Felker <dalias@libc.org>
      Acked-by: NGreg Ungerer <gerg@uclinux.org>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Oleg Endo <oleg.endo@t-online.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1bde925d
    • R
      coredump: add DAX filtering for FDPIC ELF coredumps · ab27a8d0
      Ross Zwisler 提交于
      Add explicit filtering for DAX mappings to FDPIC ELF coredump.  This is
      useful because DAX mappings have the potential to be very large.
      
      This patch has only been compile tested.
      Signed-off-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
      Acked-by: NJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      ab27a8d0
  5. 26 10月, 2015 1 次提交
  6. 09 10月, 2014 1 次提交
  7. 09 11月, 2013 6 次提交
  8. 25 10月, 2013 1 次提交
  9. 01 5月, 2013 1 次提交
  10. 30 4月, 2013 1 次提交
  11. 26 4月, 2013 1 次提交
  12. 23 2月, 2013 1 次提交
  13. 28 1月, 2013 1 次提交
    • F
      cputime: Use accessors to read task cputime stats · 6fac4829
      Frederic Weisbecker 提交于
      This is in preparation for the full dynticks feature. While
      remotely reading the cputime of a task running in a full
      dynticks CPU, we'll need to do some extra-computation. This
      way we can account the time it spent tickless in userspace
      since its last cputime snapshot.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      6fac4829
  14. 29 11月, 2012 1 次提交
  15. 09 10月, 2012 1 次提交
    • K
      mm: kill vma flag VM_RESERVED and mm->reserved_vm counter · 314e51b9
      Konstantin Khlebnikov 提交于
      A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
      currently it lost original meaning but still has some effects:
      
       | effect                 | alternative flags
      -+------------------------+---------------------------------------------
      1| account as reserved_vm | VM_IO
      2| skip in core dump      | VM_IO, VM_DONTDUMP
      3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      4| do not mlock           | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      
      This patch removes reserved_vm counter from mm_struct.  Seems like nobody
      cares about it, it does not exported into userspace directly, it only
      reduces total_vm showed in proc.
      
      Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.
      
      remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
      remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.
      
      [akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
      Cc: Matt Helsley <matthltc@us.ibm.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      314e51b9
  16. 06 10月, 2012 1 次提交
  17. 20 9月, 2012 1 次提交
  18. 16 5月, 2012 1 次提交
  19. 21 4月, 2012 1 次提交
    • L
      VM: add "vm_mmap()" helper function · 6be5ceb0
      Linus Torvalds 提交于
      This continues the theme started with vm_brk() and vm_munmap():
      vm_mmap() does the same thing as do_mmap(), but additionally does the
      required VM locking.
      
      This uninlines (and rewrites it to be clearer) do_mmap(), which sadly
      duplicates it in mm/mmap.c and mm/nommu.c.  But that way we don't have
      to export our internal do_mmap_pgoff() function.
      
      Some day we hopefully don't have to export do_mmap() either, if all
      modular users can become the simpler vm_mmap() instead.  We're actually
      very close to that already, with the notable exception of the (broken)
      use in i810, and a couple of stragglers in binfmt_elf.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6be5ceb0
  20. 29 3月, 2012 1 次提交
    • D
      Add #includes needed to permit the removal of asm/system.h · 96f951ed
      David Howells 提交于
      asm/system.h is a cause of circular dependency problems because it contains
      commonly used primitive stuff like barrier definitions and uncommonly used
      stuff like switch_to() that might require MMU definitions.
      
      asm/system.h has been disintegrated by this point on all arches into the
      following common segments:
      
       (1) asm/barrier.h
      
           Moved memory barrier definitions here.
      
       (2) asm/cmpxchg.h
      
           Moved xchg() and cmpxchg() here.  #included in asm/atomic.h.
      
       (3) asm/bug.h
      
           Moved die() and similar here.
      
       (4) asm/exec.h
      
           Moved arch_align_stack() here.
      
       (5) asm/elf.h
      
           Moved AT_VECTOR_SIZE_ARCH here.
      
       (6) asm/switch_to.h
      
           Moved switch_to() here.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      96f951ed
  21. 21 3月, 2012 2 次提交
  22. 20 7月, 2011 1 次提交
  23. 07 7月, 2011 1 次提交
  24. 01 6月, 2010 1 次提交
  25. 28 4月, 2010 1 次提交
  26. 25 3月, 2010 1 次提交
  27. 07 3月, 2010 6 次提交
    • M
      coredump: pass mm->flags as a coredump parameter for consistency · 30736a4d
      Masami Hiramatsu 提交于
      Pass mm->flags as a coredump parameter for consistency.
      
       ---
      1787         if (mm->core_state || !get_dumpable(mm)) {  <- (1)
      1788                 up_write(&mm->mmap_sem);
      1789                 put_cred(cred);
      1790                 goto fail;
      1791         }
      1792
      [...]
      1798         if (get_dumpable(mm) == 2) {    /* Setuid core dump mode */ <-(2)
      1799                 flag = O_EXCL;          /* Stop rewrite attacks */
      1800                 cred->fsuid = 0;        /* Dump root private */
      1801         }
       ---
      
      Since dumpable bits are not protected by lock, there is a chance to change
      these bits between (1) and (2).
      
      To solve this issue, this patch copies mm->flags to
      coredump_params.mm_flags at the beginning of do_coredump() and uses it
      instead of get_dumpable() while dumping core.
      
      This copy is also passed to binfmt->core_dump, since elf*_core_dump() uses
      dump_filter bits in mm->flags.
      
      [akpm@linux-foundation.org: fix merge]
      Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Acked-by: NRoland McGrath <roland@redhat.com>
      Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Reviewed-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      30736a4d
    • D
      elf coredump: add extended numbering support · 8d9032bb
      Daisuke HATAYAMA 提交于
      The current ELF dumper implementation can produce broken corefiles if
      program headers exceed 65535.  This number is determined by the number of
      vmas which the process have.  In particular, some extreme programs may use
      more than 65535 vmas.  (If you google max_map_count, you can find some
      users facing this problem.) This kind of program never be able to generate
      correct coredumps.
      
      This patch implements ``extended numbering'' that uses sh_info field of
      the first section header instead of e_phnum field in order to represent
      upto 4294967295 vmas.
      
      This is supported by
      AMD64-ABI(http://www.x86-64.org/documentation.html) and
      Solaris(http://docs.sun.com/app/docs/doc/817-1984/).
      Of course, we are preparing patches for gdb and binutils.
      Signed-off-by: NDaisuke HATAYAMA <d.hatayama@jp.fujitsu.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Greg Ungerer <gerg@snapgear.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d9032bb
    • D
      elf coredump: make offset calculation process and writing process explicit · 93eb211e
      Daisuke HATAYAMA 提交于
      By the next patch, elf_core_dump() and elf_fdpic_core_dump() will support
      extended numbering and so will produce the corefiles with section header
      table in a special case.
      
      The problem is the process of writing a file header offset of the section
      header table into e_shoff field of the ELF header.  ELF header is
      positioned at the beginning of the corefile, while section header at the
      end.  So, we need to take which of the following ways:
      
       1. Seek backward to retry writing operation for ELF header
          after writing process for a whole part
      
       2. Make offset calculation process and writing process
          totally sequential
      
      The clause 1.  is not always possible: one cannot assume that file system
      supports seek function.  Consider the no_llseek case.
      
      Therefore, this patch adopts the clause 2.
      Signed-off-by: NDaisuke HATAYAMA <d.hatayama@jp.fujitsu.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Greg Ungerer <gerg@snapgear.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      93eb211e
    • D
      elf coredump: replace ELF_CORE_EXTRA_* macros by functions · 1fcccbac
      Daisuke HATAYAMA 提交于
      elf_core_dump() and elf_fdpic_core_dump() use #ifdef and the corresponding
      macro for hiding _multiline_ logics in functions.  This patch removes
      #ifdef and replaces ELF_CORE_EXTRA_* by corresponding functions.  For
      architectures not implemeonting ELF_CORE_EXTRA_*, we use weak functions in
      order to reduce a range of modification.
      
      This cleanup is for my next patches, but I think this cleanup itself is
      worth doing regardless of my firnal purpose.
      Signed-off-by: NDaisuke HATAYAMA <d.hatayama@jp.fujitsu.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Greg Ungerer <gerg@snapgear.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1fcccbac
    • D
      coredump: move dump_write() and dump_seek() into a header file · 088e7af7
      Daisuke HATAYAMA 提交于
      My next patch will replace ELF_CORE_EXTRA_* macros by functions, putting
      them into other newly created *.c files.  Then, each files will contain
      dump_write(), where each pair of binfmt_*.c and elfcore.c should be the
      same.  So, this patch moves them into a header file with dump_seek().
      Also, the patch deletes confusing DUMP_WRITE macros in each files.
      Signed-off-by: NDaisuke HATAYAMA <d.hatayama@jp.fujitsu.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Greg Ungerer <gerg@snapgear.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      088e7af7
    • D
      coredump: unify dump_seek() implementations for each binfmt_*.c · 05f47fda
      Daisuke HATAYAMA 提交于
      The current ELF dumper can produce broken corefiles if program headers
      exceed 65535.  In particular, the program in 64-bit environment often
      demands more than 65535 mmaps.  If you google max_map_count, then you can
      find many users facing this problem.
      
      Solaris has already dealt with this issue, and other OSes have also
      adopted the same method as in Solaris.  Currently, Sun's document and AMD
      64 ABI include the description for the extension, where they call the
      extension Extended Numbering.  See Reference for further information.
      
      I believe that linux kernel should adopt the same way as they did, so I've
      written this patch.
      
      I am also preparing for patches of GDB and binutils.
      
      How to fix
      ==========
      
      In new dumping process, there are two cases according to weather or
      not the number of program headers is equal to or more than 65535.
      
       - if less than 65535, the produced corefile format is exactly the same
         as the ordinary one.
      
       - if equal to or more than 65535, then e_phnum field is set to newly
         introduced constant PN_XNUM(0xffff) and the actual number of program
         headers is set to sh_info field of the section header at index 0.
      
      Compatibility Concern
      =====================
      
       * As already mentioned in Summary, Sun and AMD64 has already adopted
         this.  See Reference.
      
       * There are four combinations according to whether kernel and userland
         tools are respectively modified or not.  The next table summarizes
         shortly for each combination.
      
                        ---------------------------------------------
                           Original Kernel    |   Modified Kernel
                        ---------------------------------------------
          	            < 65535  | >= 65535 | < 65535  | >= 65535
        -------------------------------------------------------------
         Original Tools |    OK    |  broken  |   OK     | broken (#)
        -------------------------------------------------------------
         Modified Tools |    OK    |  broken  |   OK     |    OK
        -------------------------------------------------------------
      
        Note that there is no case that `OK' changes to `broken'.
      
        (#) Although this case remains broken, O-M behaves better than
        O-O. That is, while in O-O case e_phnum field would be extremely
        small due to integer overflow, in O-M case it is guaranteed to be at
        least 65535 by being set to PN_XNUM(0xFFFF), much closer to the
        actual correct value than the O-O case.
      
      Test Program
      ============
      
      Here is a test program mkmmaps.c that is useful to produce the
      corefile with many mmaps. To use this, please take the following
      steps:
      
      $ ulimit -c unlimited
      $ sysctl vm.max_map_count=70000 # default 65530 is too small
      $ sysctl fs.file-max=70000
      $ mkmmaps 65535
      
      Then, the program will abort and a corefile will be generated.
      
      If failed, there are two cases according to the error message
      displayed.
      
       * ``out of memory'' means vm.max_map_count is still smaller
      
       * ``too many open files'' means fs.file-max is still smaller
      
      So, please change it to a larger value, and then retry it.
      
      mkmmaps.c
      ==
      #include <stdio.h>
      #include <stdlib.h>
      #include <sys/mman.h>
      #include <fcntl.h>
      #include <unistd.h>
      int main(int argc, char **argv)
      {
      	int maps_num;
      	if (argc < 2) {
      		fprintf(stderr, "mkmmaps [number of maps to be created]\n");
      		exit(1);
      	}
      	if (sscanf(argv[1], "%d", &maps_num) == EOF) {
      		perror("sscanf");
      		exit(2);
      	}
      	if (maps_num < 0) {
      		fprintf(stderr, "%d is invalid\n", maps_num);
      		exit(3);
      	}
      	for (; maps_num > 0; --maps_num) {
      		if (MAP_FAILED == mmap((void *)NULL, (size_t) 1, PROT_READ,
      					MAP_SHARED | MAP_ANONYMOUS, (int) -1,
      					(off_t) NULL)) {
      			perror("mmap");
      			exit(4);
      		}
      	}
      	abort();
      	{
      		char buffer[128];
      		sprintf(buffer, "wc -l /proc/%u/maps", getpid());
      		system(buffer);
      	}
      	return 0;
      }
      
      Tested on i386, ia64 and um/sys-i386.
      Built on sh4 (which covers fs/binfmt_elf_fdpic.c)
      
      References
      ==========
      
       - Sun microsystems: Linker and Libraries.
         Part No: 817-1984-17, September 2008.
         URL: http://docs.sun.com/app/docs/doc/817-1984
      
       - System V ABI AMD64 Architecture Processor Supplement
         Draft Version 0.99., May 11, 2009.
         URL: http://www.x86-64.org/
      
      This patch:
      
      There are three different definitions for dump_seek() functions in
      binfmt_aout.c, binfmt_elf.c and binfmt_elf_fdpic.c, respectively.  The
      only for binfmt_elf.c.
      
      My next patch will move dump_seek() into a header file in order to share
      the same implementations for dump_write() and dump_seek().  As the first
      step, this patch unify these three definitions for dump_seek() by applying
      the past commits that have been applied only for binfmt_elf.c.
      
      Specifically, the modification made here is part of the following commits:
      
        * d025c9db
        * 7f14daa1
      
      This patch does not change a shape of corefiles.
      Signed-off-by: NDaisuke HATAYAMA <d.hatayama@jp.fujitsu.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Greg Ungerer <gerg@snapgear.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      05f47fda
  28. 09 2月, 2010 1 次提交