1. 22 9月, 2009 1 次提交
    • A
      mm: add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions · 90f72aa5
      Arnd Bergmann 提交于
      Add a flag for mmap that will be used to request a huge page region that
      will look like anonymous memory to user space.  This is accomplished by
      using a file on the internal vfsmount.  MAP_HUGETLB is a modifier of
      MAP_ANONYMOUS and so must be specified with it.  The region will behave
      the same as a MAP_ANONYMOUS region using small pages.
      
      The patch also adds the MAP_STACK flag, which was previously defined only
      on some architectures but not on others.  Since MAP_STACK is meant to be a
      hint only, architectures can define it without assigning a specific
      meaning to it.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Eric B Munson <ebmunson@us.ibm.com>
      Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
      Cc: David Rientjes <rientjes@google.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      90f72aa5
  2. 12 6月, 2009 1 次提交
  3. 16 1月, 2009 1 次提交
    • S
      m68k,m68knommu: merge header files · 49148020
      Sam Ravnborg 提交于
      Merge header files for m68k and m68knommu to the single location:
      
          arch/m68k/include/asm
      
      The majority of this patch was the result of the
      script that is included in the changelog below.
      
      The script was originally written by Arnd Bergman and
      exten by me to cover a few more files.
      
      When the header files differed the script uses the following:
      
      The original m68k file is named <file>_mm.h  [mm for memory manager]
      The m68knommu file is named <file>_no.h [no for no memory manager]
      
      The files uses the following include guard:
      
      This include gaurd works as the m68knommu toolchain set
      the __uClinux__ symbol - so this should work in userspace too.
      
      Merging the header files for m68k and m68knommu exposes the
      (unexpected?) ABI differences thus it is easier to actually
      identify these and thus to fix them.
      
      The commit has been build tested with both a m68k and
      a m68knommu toolchain - with success.
      
      The commit has also been tested with "make headers_check"
      and this patch fixes make headers_check for m68knommu.
      
      The script used:
      TARGET=arch/m68k/include/asm
      SOURCE=arch/m68knommu/include/asm
      
      INCLUDE="cachectl.h errno.h fcntl.h hwtest.h ioctls.h ipcbuf.h \
      linkage.h math-emu.h md.h mman.h movs.h msgbuf.h openprom.h \
      oplib.h poll.h posix_types.h resource.h rtc.h sembuf.h shmbuf.h \
      shm.h shmparam.h socket.h sockios.h spinlock.h statfs.h stat.h \
      termbits.h termios.h tlb.h types.h user.h"
      
      EQUAL="auxvec.h cputime.h device.h emergency-restart.h futex.h \
      ioctl.h irq_regs.h kdebug.h local.h mutex.h percpu.h \
      sections.h topology.h"
      
      NOMUUFILES="anchor.h bootstd.h coldfire.h commproc.h dbg.h \
      elia.h flat.h m5206sim.h m520xsim.h m523xsim.h m5249sim.h \
      m5272sim.h m527xsim.h m528xsim.h m5307sim.h m532xsim.h \
      m5407sim.h m68360_enet.h m68360.h m68360_pram.h m68360_quicc.h \
      m68360_regs.h MC68328.h MC68332.h MC68EZ328.h MC68VZ328.h \
      mcfcache.h mcfdma.h mcfmbus.h mcfne.h mcfpci.h mcfpit.h \
      mcfsim.h mcfsmc.h mcftimer.h mcfuart.h mcfwdebug.h \
      nettel.h quicc_simple.h smp.h"
      
      FILES="atomic.h bitops.h bootinfo.h bug.h bugs.h byteorder.h cache.h \
      cacheflush.h checksum.h current.h delay.h div64.h \
      dma-mapping.h dma.h elf.h entry.h fb.h fpu.h hardirq.h hw_irq.h io.h \
      irq.h kmap_types.h machdep.h mc146818rtc.h mmu.h mmu_context.h \
      module.h page.h page_offset.h param.h pci.h pgalloc.h \
      pgtable.h processor.h ptrace.h scatterlist.h segment.h \
      setup.h sigcontext.h siginfo.h signal.h string.h system.h swab.h \
      thread_info.h timex.h tlbflush.h traps.h uaccess.h ucontext.h \
      unaligned.h unistd.h"
      
      mergefile() {
      	BASE=${1%.h}
      	git mv ${SOURCE}/$1 ${TARGET}/${BASE}_no.h
      	git mv ${TARGET}/$1 ${TARGET}/${BASE}_mm.h
      
      cat << EOF > ${TARGET}/$1
      EOF
      
      	git add ${TARGET}/$1
      }
      
      set -e
      
      mkdir -p ${TARGET}
      
      git mv include/asm-m68k/* ${TARGET}
      rmdir include/asm-m68k
      
      git rm ${SOURCE}/Kbuild
      for F in $INCLUDE $EQUAL; do
      	git rm ${SOURCE}/$F
      done
      
      for F in $NOMUUFILES; do
      	git mv ${SOURCE}/$F ${TARGET}/$F
      done
      
      for F in $FILES ; do
      	mergefile $F
      done
      
      rmdir arch/m68knommu/include/asm
      rmdir arch/m68knommu/include
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      49148020
  4. 16 2月, 2006 1 次提交
  5. 15 2月, 2006 1 次提交
    • M
      [PATCH] madvise MADV_DONTFORK/MADV_DOFORK · f8225661
      Michael S. Tsirkin 提交于
      Currently, copy-on-write may change the physical address of a page even if the
      user requested that the page is pinned in memory (either by mlock or by
      get_user_pages).  This happens if the process forks meanwhile, and the parent
      writes to that page.  As a result, the page is orphaned: in case of
      get_user_pages, the application will never see any data hardware DMA's into
      this page after the COW.  In case of mlock'd memory, the parent is not getting
      the realtime/security benefits of mlock.
      
      In particular, this affects the Infiniband modules which do DMA from and into
      user pages all the time.
      
      This patch adds madvise options to control whether memory range is inherited
      across fork.  Useful e.g.  for when hardware is doing DMA from/into these
      pages.  Could also be useful to an application wanting to speed up its forks
      by cutting large areas out of consideration.
      Signed-off-by: NMichael S. Tsirkin <mst@mellanox.co.il>
      Acked-by: NHugh Dickins <hugh@veritas.com>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f8225661
  6. 07 1月, 2006 1 次提交
    • B
      [PATCH] madvise(MADV_REMOVE): remove pages from tmpfs shm backing store · f6b3ec23
      Badari Pulavarty 提交于
      Here is the patch to implement madvise(MADV_REMOVE) - which frees up a
      given range of pages & its associated backing store.  Current
      implementation supports only shmfs/tmpfs and other filesystems return
      -ENOSYS.
      
      "Some app allocates large tmpfs files, then when some task quits and some
      client disconnect, some memory can be released.  However the only way to
      release tmpfs-swap is to MADV_REMOVE". - Andrea Arcangeli
      
      Databases want to use this feature to drop a section of their bufferpool
      (shared memory segments) - without writing back to disk/swap space.
      
      This feature is also useful for supporting hot-plug memory on UML.
      
      Concerns raised by Andrew Morton:
      
      - "We have no plan for holepunching!  If we _do_ have such a plan (or
        might in the future) then what would the API look like?  I think
        sys_holepunch(fd, start, len), so we should start out with that."
      
      - Using madvise is very weird, because people will ask "why do I need to
        mmap my file before I can stick a hole in it?"
      
      - None of the other madvise operations call into the filesystem in this
        manner.  A broad question is: is this capability an MM operation or a
        filesytem operation?  truncate, for example, is a filesystem operation
        which sometimes has MM side-effects.  madvise is an mm operation and with
        this patch, it gains FS side-effects, only they're really, really
        significant ones."
      
      Comments:
      
      - Andrea suggested the fs operation too but then it's more efficient to
        have it as a mm operation with fs side effects, because they don't
        immediatly know fd and physical offset of the range.  It's possible to
        fixup in userland and to use the fs operation but it's more expensive,
        the vmas are already in the kernel and we can use them.
      
      Short term plan &  Future Direction:
      
      - We seem to need this interface only for shmfs/tmpfs files in the short
        term.  We have to add hooks into the filesystem for correctness and
        completeness.  This is what this patch does.
      
      - In the future, plan is to support both fs and mmap apis also.  This
        also involves (other) filesystem specific functions to be implemented.
      
      - Current patch doesn't support VM_NONLINEAR - which can be addressed in
        the future.
      Signed-off-by: NBadari Pulavarty <pbadari@us.ibm.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Andrea Arcangeli <andrea@suse.de>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Ulrich Drepper <drepper@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f6b3ec23
  7. 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