1. 07 Jan, 2010 5 commits
    • Linus Torvalds's avatar
      Merge branch 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel · 635b3c9d
      Linus Torvalds authored
      * 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: (23 commits)
        drm/i915: remove full registers dump debug
        drm/i915: Add DP dpll limit on ironlake and use existing DPLL search function
        drm/i915: Select the correct BPC for LVDS on Ironlake
        drm/i915: Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake
        drm/i915: Enable/disable the dithering for LVDS based on VBT setting
        drm/i915: Permit pinning whilst the device is 'suspended'
        drm/i915: Hold struct mutex whilst pinning power context bo.
        drm/i915: fix unused var
        drm/i915: Storage class should be before const qualifier
        drm/i915: remove render reclock support
        drm/i915: Fix RC6 suspend/resume
        drm/i915: execbuf2 support
        drm/i915: Reload hangcheck timer too for Ironlake
        drm/i915: only enable hotplug for detected outputs
        drm/i915: Track whether cursor needs physical address in intel_device_info
        drm/i915: Implement IS_* macros using static tables
        drm/i915: Move PCI IDs into i915 driver
        drm/i915: Update LVDS connector status when receiving ACPI LID event
        drm/i915: Add MALATA PC-81005 to ACPI LID quirk list
        drm/i915: implement new pm ops for i915
        ...
      635b3c9d
    • Jie Zhang's avatar
      NOMMU: Use copy_*_user_page() in access_process_vm() · 7959722b
      Jie Zhang authored
      The MMU code uses the copy_*_user_page() variants in access_process_vm()
      rather than copy_*_user() as the former includes an icache flush.  This
      is important when doing things like setting software breakpoints with
      gdb.  So switch the NOMMU code over to do the same.
      
      This patch makes the reasonable assumption that copy_from_user_page()
      won't fail - which is probably fine, as we've checked the VMA from which
      we're copying is usable, and the copy is not allowed to cross VMAs.  The
      one case where it might go wrong is if the VMA is a device rather than
      RAM, and that device returns an error which - in which case rubbish will
      be returned rather than EIO.
      Signed-off-by: default avatarJie Zhang <jie.zhang@analog.com>
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarDavid McCullough <david_mccullough@mcafee.com>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Acked-by: default avatarGreg Ungerer <gerg@uclinux.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7959722b
    • Mike Frysinger's avatar
      NOMMU: Avoiding duplicate icache flushes of shared maps · cfe79c00
      Mike Frysinger authored
      When working with FDPIC, there are many shared mappings of read-only
      code regions between applications (the C library, applet packages like
      busybox, etc.), but the current do_mmap_pgoff() function will issue an
      icache flush whenever a VMA is added to an MM instead of only doing it
      when the map is initially created.
      
      The flush can instead be done when a region is first mmapped PROT_EXEC.
      Note that we may not rely on the first mapping of a region being
      executable - it's possible for it to be PROT_READ only, so we have to
      remember whether we've flushed the region or not, and then flush the
      entire region when a bit of it is made executable.
      
      However, this also affects the brk area.  That will no longer be
      executable.  We can mprotect() it to PROT_EXEC on MPU-mode kernels, but
      for NOMMU mode kernels, when it increases the brk allocation, making
      sys_brk() flush the extra from the icache should suffice.  The brk area
      probably isn't used by NOMMU programs since the brk area can only use up
      the leavings from the stack allocation, where the stack allocation is
      larger than requested.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cfe79c00
    • Mike Frysinger's avatar
      FDPIC: Respect PT_GNU_STACK exec protection markings when creating NOMMU stack · 04e4f2b1
      Mike Frysinger authored
      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: default avatarMike Frysinger <vapier@gentoo.org>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      04e4f2b1
    • Linus Torvalds's avatar
      Merge branch 'for-2.6.33' of git://linux-nfs.org/~bfields/linux · 93939f4e
      Linus Torvalds authored
      * 'for-2.6.33' of git://linux-nfs.org/~bfields/linux:
        sunrpc: fix peername failed on closed listener
        nfsd: make sure data is on disk before calling ->fsync
        nfsd: fix "insecure" export option
      93939f4e
  2. 06 Jan, 2010 28 commits
  3. 05 Jan, 2010 7 commits