1. 28 11月, 2012 1 次提交
    • H
      x86-32: Unbreak booting on some 486 clones · 6662c34f
      H. Peter Anvin 提交于
      There appear to have been some 486 clones, including the "enhanced"
      version of Am486, which have CPUID but not CR4.  These 486 clones had
      only the FPU flag, if any, unlike the Intel 486s with CPUID, which
      also had VME and therefore needed CR4.
      
      Therefore, look at the basic CPUID flags and require at least one bit
      other than bit 0 before we modify CR4.
      
      Thanks to Christian Ludloff of sandpile.org for confirming this as a
      problem.
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      6662c34f
  2. 27 11月, 2012 1 次提交
  3. 26 11月, 2012 1 次提交
  4. 24 11月, 2012 3 次提交
  5. 23 11月, 2012 1 次提交
  6. 22 11月, 2012 2 次提交
    • A
      [PARISC] fix user-triggerable panic on parisc · 441a179d
      Al Viro 提交于
      int sys32_rt_sigprocmask(int how, compat_sigset_t __user *set, compat_sigset_t __user *oset,
                                          unsigned int sigsetsize)
      {
              sigset_t old_set, new_set;
              int ret;
      
              if (set && get_sigset32(set, &new_set, sigsetsize))
      
      ...
      static int
      get_sigset32(compat_sigset_t __user *up, sigset_t *set, size_t sz)
      {
              compat_sigset_t s;
              int r;
      
              if (sz != sizeof *set) panic("put_sigset32()");
      
      In other words, rt_sigprocmask(69, (void *)69, 69) done by 32bit process
      will promptly panic the box.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      441a179d
    • I
      ARM - OMAP: ads7846: fix pendown debounce setting · 0a0d6285
      Igor Grinberg 提交于
      Commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code) have enabled the
      pendown GPIO debounce time setting by the below sequence:
      
        gpio_request_one()
        gpio_set_debounce()
        gpio_free()
      
      It also revealed a bug in the OMAP GPIO handling code which prevented
      the GPIO debounce clock to be disabled and CORE transition to low power
      states.
      
      Commit c9c55d92 (gpio/omap: fix off-mode bug: clear debounce settings on
      free/reset) fixes the OMAP GPIO handling code by making sure that the
      GPIO debounce clock gets disabled if no GPIO is requested from current
      bank.
      
      While fixing the OMAP GPIO handling code (in the right way), the above
      commit makes the gpio_request->set_debounce->free sequence invalid as
      after freeing the GPIO, the debounce settings are lost.
      
      Fix the debounce settings by moving the debounce initialization to the
      actual GPIO requesting code - the ads7846 driver.
      Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      0a0d6285
  7. 21 11月, 2012 6 次提交
  8. 20 11月, 2012 1 次提交
  9. 19 11月, 2012 2 次提交
    • L
      ARM: davinci: dm644x: fix out range signal for ED · e37212aa
      Lad, Prabhakar 提交于
      Fix the video clock setting when custom timings are used with
      pclock <= 27MHz. Existing video clock selection uses PLL2 mode
      which results in a 54MHz clock whereas using the MXI mode results
      in a 27MHz clock (which is the one actually desired).
      
      This bug affects the Enhanced Definition (ED) support on DM644x.
      Without this patch, out-range signals errors are were observed on
      the TV when viewing ED. An out-of-range signal is often caused when
      the field rate is above the rate that the television will handle.
      Signed-off-by: NLad, Prabhakar <prabhakar.lad@ti.com>
      Signed-off-by: NManjunath Hadli <manjunath.hadli@ti.com>
      Cc: Sekhar Nori <nsekhar@ti.com>
      [nsekhar@ti.com: reword commit message based on on-list discussion]
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      e37212aa
    • A
      sparc64: not any error from do_sigaltstack() should fail rt_sigreturn() · fae2ae2a
      Al Viro 提交于
      If a signal handler is executed on altstack and another signal comes,
      we will end up with rt_sigreturn() on return from the second handler
      getting -EPERM from do_sigaltstack().  It's perfectly OK, since we
      are not asking to change the settings; in fact, they couldn't have been
      changed during the second handler execution exactly because we'd been
      on altstack all along.  64bit sigreturn on sparc treats any error from
      do_sigaltstack() as "SIGSEGV now"; we need to switch to the same semantics
      we are using on other architectures.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fae2ae2a
  10. 18 11月, 2012 1 次提交
  11. 17 11月, 2012 3 次提交
    • A
      revert "mm: fix-up zone present pages" · 5576646f
      Andrew Morton 提交于
      Revert commit 7f1290f2 ("mm: fix-up zone present pages")
      
      That patch tried to fix a issue when calculating zone->present_pages,
      but it caused a regression on 32bit systems with HIGHMEM.  With that
      change, reset_zone_present_pages() resets all zone->present_pages to
      zero, and fixup_zone_present_pages() is called to recalculate
      zone->present_pages when the boot allocator frees core memory pages into
      buddy allocator.  Because highmem pages are not freed by bootmem
      allocator, all highmem zones' present_pages becomes zero.
      
      Various options for improving the situation are being discussed but for
      now, let's return to the 3.6 code.
      
      Cc: Jianguo Wu <wujianguo@huawei.com>
      Cc: Jiang Liu <jiang.liu@huawei.com>
      Cc: Petr Tesarik <ptesarik@suse.cz>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Tested-by: NChris Clayton <chris2553@googlemail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5576646f
    • D
      mips, arc: fix build failure · 18f69427
      David Rientjes 提交于
      Using a cross-compiler to fix another issue, the following build error
      occurred for mips defconfig:
      
        arch/mips/fw/arc/misc.c: In function 'ArcHalt':
        arch/mips/fw/arc/misc.c:25:2: error: implicit declaration of function 'local_irq_disable'
      
      Fix it up by including irqflags.h.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      18f69427
    • T
      KVM: x86: Fix invalid secondary exec controls in vmx_cpuid_update() · 29282fde
      Takashi Iwai 提交于
      The commit [ad756a16: KVM: VMX: Implement PCID/INVPCID for guests with
      EPT] introduced the unconditional access to SECONDARY_VM_EXEC_CONTROL,
      and this triggers kernel warnings like below on old CPUs:
      
          vmwrite error: reg 401e value a0568000 (err 12)
          Pid: 13649, comm: qemu-kvm Not tainted 3.7.0-rc4-test2+ #154
          Call Trace:
           [<ffffffffa0558d86>] vmwrite_error+0x27/0x29 [kvm_intel]
           [<ffffffffa054e8cb>] vmcs_writel+0x1b/0x20 [kvm_intel]
           [<ffffffffa054f114>] vmx_cpuid_update+0x74/0x170 [kvm_intel]
           [<ffffffffa03629b6>] kvm_vcpu_ioctl_set_cpuid2+0x76/0x90 [kvm]
           [<ffffffffa0341c67>] kvm_arch_vcpu_ioctl+0xc37/0xed0 [kvm]
           [<ffffffff81143f7c>] ? __vunmap+0x9c/0x110
           [<ffffffffa0551489>] ? vmx_vcpu_load+0x39/0x1a0 [kvm_intel]
           [<ffffffffa0340ee2>] ? kvm_arch_vcpu_load+0x52/0x1a0 [kvm]
           [<ffffffffa032dcd4>] ? vcpu_load+0x74/0xd0 [kvm]
           [<ffffffffa032deb0>] kvm_vcpu_ioctl+0x110/0x5e0 [kvm]
           [<ffffffffa032e93d>] ? kvm_dev_ioctl+0x4d/0x4a0 [kvm]
           [<ffffffff8117dc6f>] do_vfs_ioctl+0x8f/0x530
           [<ffffffff81139d76>] ? remove_vma+0x56/0x60
           [<ffffffff8113b708>] ? do_munmap+0x328/0x400
           [<ffffffff81187c8c>] ? fget_light+0x4c/0x100
           [<ffffffff8117e1a1>] sys_ioctl+0x91/0xb0
           [<ffffffff815a942d>] system_call_fastpath+0x1a/0x1f
      
      This patch adds a check for the availability of secondary exec
      control to avoid these warnings.
      
      Cc: <stable@vger.kernel.org> [v3.6+]
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      29282fde
  12. 16 11月, 2012 5 次提交
  13. 15 11月, 2012 2 次提交
    • J
      [PARISC] fix virtual aliasing issue in get_shared_area() · 949a05d0
      James Bottomley 提交于
      On Thu, 2012-11-01 at 16:45 -0700, Michel Lespinasse wrote:
      > Looking at the arch/parisc/kernel/sys_parisc.c implementation of
      > get_shared_area(), I do have a concern though. The function basically
      > ignores the pgoff argument, so that if one creates a shared mapping of
      > pages 0-N of a file, and then a separate shared mapping of pages 1-N
      > of that same file, both will have the same cache offset for their
      > starting address.
      >
      > This looks like this would create obvious aliasing issues. Am I
      > misreading this ? I can't understand how this could work good enough
      > to be undetected, so there must be something I'm missing here ???
      
      This turns out to be correct and we need to pay attention to the pgoff as
      well as the address when creating the virtual address for the area.
      Fortunately, the bug is rarely triggered as most applications which use pgoff
      tend to use large values (git being the primary one, and it uses pgoff in
      multiples of 16MB) which are larger than our cache coherency modulus, so the
      problem isn't often seen in practise.
      Reported-by: NMichel Lespinasse <walken@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      949a05d0
    • J
      x86, mm: Correct vmflag test for checking VM_HUGETLB · ddd32b42
      Joonsoo Kim 提交于
      commit 611ae8e3('enable tlb flush range
      support for x86') change flush_tlb_mm_range() considerably. After this,
      we test whether vmflag equal to VM_HUGETLB and it may be always failed,
      because vmflag usually has other flags simultaneously.
      Our intention is to check whether this vma is for hughtlb, so correct it
      according to this purpose.
      Signed-off-by: NJoonsoo Kim <js1304@gmail.com>
      Acked-by: NAlex Shi <alex.shi@intel.com>
      Link: http://lkml.kernel.org/r/1352740656-19417-1-git-send-email-js1304@gmail.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      ddd32b42
  14. 14 11月, 2012 1 次提交
  15. 13 11月, 2012 7 次提交
    • R
      MIPS: Malta: Fix interupt number of CBUS UART. · 225ae5fd
      Ralf Baechle 提交于
      The CBUS UART's interrupt number was wrong conflicting with the interrupt
      being tied to the Intel PIIX4.  Since the PIIX4's interrupt is registered
      before the CBUS UART which is not being used on most systems this would
      not be noticed.
      
      Attempts to open the ttyS2 CBUS UART would result in:
      
      genirq: Flags mismatch irq 18. 00000000 (serial) vs. 00010000 (XT-PIC cascade)
      serial_link_irq_chain: request failed: -16 for irq: 18
      
      Qemu was written to match the kernel so will need to be fixed also.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      225ae5fd
    • H
      s390/mm: have 16 byte aligned struct pages · 4bffbb34
      Heiko Carstens 提交于
      Select HAVE_ALIGNED_STRUCT_PAGE on s390, so that the slub allocator can make
      use of compare and swap double for lockless updates. This increases the size
      of struct page to 64 bytes (instead of 56 bytes), however the performance gain
      justifies the increased size:
      
      - now excactly four struct pages fit into a single cache line; the
        case that accessing a struct page causes two cache line loads
        does not exist anymore.
      - calculating the offset of a struct page within the memmap array
        is only a simple shift instead of a more expensive multiplication.
      
      A "hackbench 200 process 200" run on a 32 cpu system did show an 8% runtime
      improvement.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      4bffbb34
    • H
      s390/gup: fix access_ok() usage in __get_user_pages_fast() · 516bad44
      Heiko Carstens 提交于
      access_ok() returns always "true" on s390. Therefore all access_ok()
      invocations are rather pointless.
      However when walking page tables we need to make sure that everything
      is within bounds of the ASCE limit of the task's address space.
      So remove the access_ok() call and add the same check we have in
      get_user_pages_fast().
      Reviewed-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      516bad44
    • H
      s390/gup: add missing TASK_SIZE check to get_user_pages_fast() · d55c4c61
      Heiko Carstens 提交于
      When walking page tables we need to make sure that everything
      is within bounds of the ASCE limit of the task's address space.
      Otherwise we might calculate e.g. a pud pointer which is not
      within a pud and dereference it.
      So check against TASK_SIZE (which is the ASCE limit) before
      walking page tables.
      Reviewed-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      d55c4c61
    • P
      KVM: x86: invalid opcode oops on SET_SREGS with OSXSAVE bit set (CVE-2012-4461) · 6d1068b3
      Petr Matousek 提交于
      On hosts without the XSAVE support unprivileged local user can trigger
      oops similar to the one below by setting X86_CR4_OSXSAVE bit in guest
      cr4 register using KVM_SET_SREGS ioctl and later issuing KVM_RUN
      ioctl.
      
      invalid opcode: 0000 [#2] SMP
      Modules linked in: tun ip6table_filter ip6_tables ebtable_nat ebtables
      ...
      Pid: 24935, comm: zoog_kvm_monito Tainted: G      D      3.2.0-3-686-pae
      EIP: 0060:[<f8b9550c>] EFLAGS: 00210246 CPU: 0
      EIP is at kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm]
      EAX: 00000001 EBX: 000f387e ECX: 00000000 EDX: 00000000
      ESI: 00000000 EDI: 00000000 EBP: ef5a0060 ESP: d7c63e70
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process zoog_kvm_monito (pid: 24935, ti=d7c62000 task=ed84a0c0
      task.ti=d7c62000)
      Stack:
       00000001 f70a1200 f8b940a9 ef5a0060 00000000 00200202 f8769009 00000000
       ef5a0060 000f387e eda5c020 8722f9c8 00015bae 00000000 ed84a0c0 ed84a0c0
       c12bf02d 0000ae80 ef7f8740 fffffffb f359b740 ef5a0060 f8b85dc1 0000ae80
      Call Trace:
       [<f8b940a9>] ? kvm_arch_vcpu_ioctl_set_sregs+0x2fe/0x308 [kvm]
      ...
       [<c12bfb44>] ? syscall_call+0x7/0xb
      Code: 89 e8 e8 14 ee ff ff ba 00 00 04 00 89 e8 e8 98 48 ff ff 85 c0 74
      1e 83 7d 48 00 75 18 8b 85 08 07 00 00 31 c9 8b 95 0c 07 00 00 <0f> 01
      d1 c7 45 48 01 00 00 00 c7 45 1c 01 00 00 00 0f ae f0 89
      EIP: [<f8b9550c>] kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm] SS:ESP
      0068:d7c63e70
      
      QEMU first retrieves the supported features via KVM_GET_SUPPORTED_CPUID
      and then sets them later. So guest's X86_FEATURE_XSAVE should be masked
      out on hosts without X86_FEATURE_XSAVE, making kvm_set_cr4 with
      X86_CR4_OSXSAVE fail. Userspaces that allow specifying guest cpuid with
      X86_FEATURE_XSAVE even on hosts that do not support it, might be
      susceptible to this attack from inside the guest as well.
      
      Allow setting X86_CR4_OSXSAVE bit only if host has XSAVE support.
      Signed-off-by: NPetr Matousek <pmatouse@redhat.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      6d1068b3
    • F
      ARM: boot: Fix usage of kecho · 2d4d07b9
      Fabio Estevam 提交于
      Since commit edc88ceb (ARM: be really quiet when building with 'make -s') the
      following output is generated when building a kernel for ARM:
      
      echo '  Kernel: arch/arm/boot/Image is ready'
        Kernel: arch/arm/boot/Image is ready
        Building modules, stage 2.
      echo '  Kernel: arch/arm/boot/zImage is ready'
        Kernel: arch/arm/boot/zImage is ready
      
      As per Documentation/kbuild/makefiles.txt the correct way of using kecho is
      '@$(kecho)'.
      
      Make this change so no more unwanted 'echo' messages are displayed.
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      2d4d07b9
    • K
      ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC · 1ef43369
      Kevin Hilman 提交于
      On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is
      connected to the MSECURE input of the TWL6030 PMIC.  This signal
      controls the secure-mode operation of the PMIC.  If its not mux'd
      correctly, some functionality of the PMIC will not be accessible since
      the PMIC will be in secure mode.
      
      For example, if the TWL RTC is in secure mode, most of its registers
      are read-only, meaning (re)programming the RTC (e.g. for wakeup from
      suspend) will fail.
      
      To fix, ensure the signal is properly mux'd as output when TWL is
      intialized.
      
      This fix is required when using recent versions of u-boot (>= v2012.04.01)
      since u-boot is no longer setting the default mux for this pin.
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1ef43369
  16. 12 11月, 2012 2 次提交
    • H
      s390/topology: fix core id vs physical package id mix-up · 658e5ce7
      Heiko Carstens 提交于
      The current topology code confuses core id vs physical package id.
      
      In other words /sys/devices/system/cpu/cpuX/topology/core_id
      displays the physical_package_id (aka socket id) instead of the
      core id.
      The physical_package_id sysfs attribute always displays "-1"
      instead of the socket id.
      
      Fix this mix-up with a small patch which defines and initializes
      topology_physical_package_id correctly and fixes the broken
      core id handling.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      658e5ce7
    • M
      s390/signal: set correct address space control · fa968ee2
      Martin Schwidefsky 提交于
      If user space is running in primary mode it can switch to secondary
      or access register mode, this is used e.g. in the clock_gettime code
      of the vdso. If a signal is delivered to the user space process while
      it has been running in access register mode the signal handler is
      executed in access register mode as well which will result in a crash
      most of the time.
      
      Set the address space control bits in the PSW to the default for the
      execution of the signal handler and make sure that the previous
      address space control is restored on signal return. Take care
      that user space can not switch to the kernel address space by
      modifying the registers in the signal frame.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      fa968ee2
  17. 10 11月, 2012 1 次提交