1. 20 May, 2014 8 commits
  2. 19 May, 2014 1 commit
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2014-05-16' of git://anongit.freedesktop.org/drm-intel into drm-fixes · 4ba4801d
      Dave Airlie authored
      Intel fixes for regressions, black screens and hangs, for 3.15.
      
      * tag 'drm-intel-fixes-2014-05-16' of git://anongit.freedesktop.org/drm-intel:
        drm/i915: Increase WM memory latency values on SNB
        drm/i915: restore backlight precision when converting from ACPI
        drm/i915: Use the first mode if there is no preferred mode in the EDID
        drm/i915/dp: force eDP lane count to max available lanes on BDW
        drm/i915/vlv: reset VLV media force wake request register
        drm/i915/SDVO: For sysfs link put directory and target in correct order
        drm/i915: use lane count and link rate from VBT as minimums for eDP
        drm/i915: clean up VBT eDP link param decoding
        drm/i915: consider the source max DP lane count too
      4ba4801d
  3. 16 May, 2014 1 commit
    • Mark Salter's avatar
      arm64: fix pud_huge() for 2-level pagetables · 4797ec2d
      Mark Salter authored
      The following happens when trying to run a kvm guest on a kernel
      configured for 64k pages. This doesn't happen with 4k pages:
      
        BUG: failure at include/linux/mm.h:297/put_page_testzero()!
        Kernel panic - not syncing: BUG!
        CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF            3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1
        Call trace:
        [<fffffe0000096034>] dump_backtrace+0x0/0x16c
        [<fffffe00000961b4>] show_stack+0x14/0x1c
        [<fffffe000066e648>] dump_stack+0x84/0xb0
        [<fffffe0000668678>] panic+0xf4/0x220
        [<fffffe000018ec78>] free_reserved_area+0x0/0x110
        [<fffffe000018edd8>] free_pages+0x50/0x88
        [<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40
        [<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44
        [<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184
        [<fffffe00000a1938>] kvm_vm_release+0x10/0x1c
        [<fffffe00001edc1c>] __fput+0xb0/0x288
        [<fffffe00001ede4c>] ____fput+0xc/0x14
        [<fffffe00000d5a2c>] task_work_run+0xa8/0x11c
        [<fffffe0000095c14>] do_notify_resume+0x54/0x58
      
      In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page()
      on the stage2 pgd which leads to the BUG in put_page_testzero(). This
      happens because a pud_huge() test in unmap_range() returns true when it
      should always be false with 2-level pages tables used by 64k pages.
      This patch removes support for huge puds if 2-level pagetables are
      being used.
      Signed-off-by: default avatarMark Salter <msalter@redhat.com>
      [catalin.marinas@arm.com: removed #ifndef around PUD_SIZE check]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Cc: <stable@vger.kernel.org> # v3.11+
      4797ec2d
  4. 15 May, 2014 6 commits
  5. 14 May, 2014 6 commits
    • Linus Torvalds's avatar
      x86-64, modify_ldt: Make support for 16-bit segments a runtime option · fa81511b
      Linus Torvalds authored
      Checkin:
      
      b3b42ac2 x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
      
      disabled 16-bit segments on 64-bit kernels due to an information
      leak.  However, it does seem that people are genuinely using Wine to
      run old 16-bit Windows programs on Linux.
      
      A proper fix for this ("espfix64") is coming in the upcoming merge
      window, but as a temporary fix, create a sysctl to allow the
      administrator to re-enable support for 16-bit segments.
      
      It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
      you hit this issue and care about your old Windows program more than
      you care about a kernel stack address information leak, you can do
      
         echo 1 > /proc/sys/abi/ldt16
      
      as root (add it to your startup scripts), and you should be ok.
      
      The sysctl table is only added if you have COMPAT support enabled on
      x86-64, but I assume anybody who runs old windows binaries very much
      does that ;)
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com
      Cc: <stable@vger.kernel.org>
      fa81511b
    • James Hogan's avatar
      asm-generic: remove _STK_LIM_MAX · ffe6902b
      James Hogan authored
      _STK_LIM_MAX could be used to override the RLIMIT_STACK hard limit from
      an arch's include/uapi/asm-generic/resource.h file, but is no longer
      used since both parisc and metag removed the override. Therefore remove
      it entirely, setting the hard RLIMIT_STACK limit to RLIM_INFINITY
      directly in include/asm-generic/resource.h.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-arch@vger.kernel.org
      Cc: Helge Deller <deller@gmx.de>
      Cc: John David Anglin <dave.anglin@bell.net>
      ffe6902b
    • James Hogan's avatar
      metag: Remove _STK_LIM_MAX override · c70458f5
      James Hogan authored
      Meta overrode _STK_LIM_MAX (the default RLIMIT_STACK hard limit) to
      256MB, apparently in an attempt to prevent setup_arg_pages's
      STACK_GROWSUP code from choosing the maximum stack size of 1GB, which is
      far too large for Meta's limited virtual address space and hits a BUG_ON
      (stack_top is usually 0x3ffff000).
      
      However the commit "metag: Reduce maximum stack size to 256MB" reduces
      the absolute stack size limit to a safe value for metag. This allows the
      default _STK_LIM_MAX override to be removed, bringing the default
      behaviour in line with all other architectures. Parisc in particular
      recently removed their override of _STK_LIMT_MAX in commit e0d8898d
      (parisc: remove _STK_LIM_MAX override) since it subtly affects stack
      allocation semantics in userland. Meta's uapi/asm/resource.h can now be
      removed and switch to using generic-y.
      Suggested-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: linux-metag@vger.kernel.org
      Cc: John David Anglin <dave.anglin@bell.net>
      c70458f5
    • Helge Deller's avatar
      parisc,metag: Do not hardcode maximum userspace stack size · 042d27ac
      Helge Deller authored
      This patch affects only architectures where the stack grows upwards
      (currently parisc and metag only). On those do not hardcode the maximum
      initial stack size to 1GB for 32-bit processes, but make it configurable
      via a config option.
      
      The main problem with the hardcoded stack size is, that we have two
      memory regions which grow upwards: stack and heap. To keep most of the
      memory available for heap in a flexmap memory layout, it makes no sense
      to hard allocate up to 1GB of the memory for stack which can't be used
      as heap then.
      
      This patch makes the stack size for 32-bit processes configurable and
      uses 80MB as default value which has been in use during the last few
      years on parisc and which hasn't showed any problems yet.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: linux-parisc@vger.kernel.org
      Cc: linux-metag@vger.kernel.org
      Cc: John David Anglin <dave.anglin@bell.net>
      042d27ac
    • James Hogan's avatar
      metag: Reduce maximum stack size to 256MB · d71f290b
      James Hogan authored
      Specify the maximum stack size for arches where the stack grows upward
      (parisc and metag) in asm/processor.h rather than hard coding in
      fs/exec.c so that metag can specify a smaller value of 256MB rather than
      1GB.
      
      This fixes a BUG on metag if the RLIMIT_STACK hard limit is increased
      beyond a safe value by root. E.g. when starting a process after running
      "ulimit -H -s unlimited" it will then attempt to use a stack size of the
      maximum 1GB which is far too big for metag's limited user virtual
      address space (stack_top is usually 0x3ffff000):
      
      BUG: failure at fs/exec.c:589/shift_arg_pages()!
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: linux-parisc@vger.kernel.org
      Cc: linux-metag@vger.kernel.org
      Cc: John David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # only needed for >= v3.9 (arch/metag)
      d71f290b
    • Mikulas Patocka's avatar
      metag: fix memory barriers · 2425ce84
      Mikulas Patocka authored
      Volatile access doesn't really imply the compiler barrier. Volatile access
      is only ordered with respect to other volatile accesses, it isn't ordered
      with respect to general memory accesses. Gcc may reorder memory accesses
      around volatile access, as we can see in this simple example (if we
      compile it with optimization, both increments of *b will be collapsed to
      just one):
      
      void fn(volatile int *a, long *b)
      {
      	(*b)++;
      	*a = 10;
      	(*b)++;
      }
      
      Consequently, we need the compiler barrier after a write to the volatile
      variable, to make sure that the compiler doesn't reorder the volatile
      write with something else.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      2425ce84
  6. 13 May, 2014 11 commits
  7. 12 May, 2014 7 commits