1. 16 1月, 2016 1 次提交
  2. 07 1月, 2010 1 次提交
    • M
      FDPIC: Respect PT_GNU_STACK exec protection markings when creating NOMMU stack · 04e4f2b1
      Mike Frysinger 提交于
      The current code will load the stack size and protection markings, but
      then only use the markings in the MMU code path.  The NOMMU code path
      always passes PROT_EXEC to the mmap() call.  While this doesn't matter
      to most people whilst the code is running, it will cause a pointless
      icache flush when starting every FDPIC application.  Typically this
      icache flush will be of a region on the order of 128KB in size, or may
      be the entire icache, depending on the facilities available on the CPU.
      
      In the case where the arch default behaviour seems to be desired
      (EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine
      whether we should be setting PROT_EXEC or not.
      
      For arches that support an MPU (Memory Protection Unit - an MMU without
      the virtual mapping capability), setting PROT_EXEC or not will make an
      important difference.
      
      It should be noted that this change also affects the executability of
      the brk region, since ELF-FDPIC has that share with the stack.  However,
      this is probably irrelevant as NOMMU programs aren't likely to use the
      brk region, preferring instead allocation via mmap().
      Signed-off-by: NMike Frysinger <vapier@gentoo.org>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      04e4f2b1
  3. 12 6月, 2009 1 次提交
  4. 10 4月, 2009 1 次提交
  5. 25 7月, 2008 1 次提交
    • A
      PAGE_ALIGN(): correctly handle 64-bit values on 32-bit architectures · 27ac792c
      Andrea Righi 提交于
      On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit
      boundary. For example:
      
      	u64 val = PAGE_ALIGN(size);
      
      always returns a value < 4GB even if size is greater than 4GB.
      
      The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for
      example):
      
      #define PAGE_SHIFT      12
      #define PAGE_SIZE       (_AC(1,UL) << PAGE_SHIFT)
      #define PAGE_MASK       (~(PAGE_SIZE-1))
      ...
      #define PAGE_ALIGN(addr)       (((addr)+PAGE_SIZE-1)&PAGE_MASK)
      
      The "~" is performed on a 32-bit value, so everything in "and" with
      PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary.
      Using the ALIGN() macro seems to be the right way, because it uses
      typeof(addr) for the mask.
      
      Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in
      include/linux/mm.h.
      
      See also lkml discussion: http://lkml.org/lkml/2008/6/11/237
      
      [akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c]
      [akpm@linux-foundation.org: fix v850]
      [akpm@linux-foundation.org: fix powerpc]
      [akpm@linux-foundation.org: fix arm]
      [akpm@linux-foundation.org: fix mips]
      [akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c]
      [akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c]
      [akpm@linux-foundation.org: fix powerpc]
      Signed-off-by: NAndrea Righi <righi.andrea@gmail.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>
      27ac792c
  6. 09 2月, 2008 1 次提交
    • M
      CONFIG_HIGHPTE vs. sub-page page tables. · 2f569afd
      Martin Schwidefsky 提交于
      Background: I've implemented 1K/2K page tables for s390.  These sub-page
      page tables are required to properly support the s390 virtualization
      instruction with KVM.  The SIE instruction requires that the page tables
      have 256 page table entries (pte) followed by 256 page status table entries
      (pgste).  The pgstes are only required if the process is using the SIE
      instruction.  The pgstes are updated by the hardware and by the hypervisor
      for a number of reasons, one of them is dirty and reference bit tracking.
      To avoid wasting memory the standard pte table allocation should return
      1K/2K (31/64 bit) and 2K/4K if the process is using SIE.
      
      Problem: Page size on s390 is 4K, page table size is 1K or 2K.  That means
      the s390 version for pte_alloc_one cannot return a pointer to a struct
      page.  Trouble is that with the CONFIG_HIGHPTE feature on x86 pte_alloc_one
      cannot return a pointer to a pte either, since that would require more than
      32 bit for the return value of pte_alloc_one (and the pte * would not be
      accessible since its not kmapped).
      
      Solution: The only solution I found to this dilemma is a new typedef: a
      pgtable_t.  For s390 pgtable_t will be a (pte *) - to be introduced with a
      later patch.  For everybody else it will be a (struct page *).  The
      additional problem with the initialization of the ptl lock and the
      NR_PAGETABLE accounting is solved with a constructor pgtable_page_ctor and
      a destructor pgtable_page_dtor.  The page table allocation and free
      functions need to call these two whenever a page table page is allocated or
      freed.  pmd_populate will get a pgtable_t instead of a struct page pointer.
       To get the pgtable_t back from a pmd entry that has been installed with
      pmd_populate a new function pmd_pgtable is added.  It replaces the pmd_page
      call in free_pte_range and apply_to_pte_range.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.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>
      2f569afd
  7. 08 2月, 2008 1 次提交
  8. 06 2月, 2008 1 次提交
  9. 02 2月, 2007 1 次提交
  10. 26 4月, 2006 1 次提交
  11. 28 3月, 2006 1 次提交
  12. 29 11月, 2005 1 次提交
    • D
      [PATCH] FRV: Make the FRV arch work again · 8080f231
      David Howells 提交于
      The attached patch implements a bunch of small changes to the FRV arch to
      make it work again.
      
      It deals with the following problems:
      
       (1) SEM_DEBUG should be SEMAPHORE_DEBUG.
      
       (2) The argument list to pcibios_penalize_isa_irq() has changed.
      
       (3) CONFIG_HIGHMEM can't be used directly in #if as it may not be defined.
      
       (4) page->private is no longer directly accessible.
      
       (5) linux/hardirq.h assumes asm/hardirq.h will include linux/irq.h
      
       (6) The IDE MMIO access functions are given pointers, not integers, and so
           get type casting errors.
      
       (7) __pa() is passed an explicit u64 type in drivers/char/mem.c, but that
           can't be cast directly to a pointer on a 32-bit platform.
      
       (8) SEMAPHORE_DEBUG should not be contingent on WAITQUEUE_DEBUG as that no
           longer exists.
      
       (9) PREEMPT_ACTIVE is too low a value.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8080f231
  13. 05 9月, 2005 1 次提交
  14. 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